Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Coolcrab

Members
 View Profile  See their activity

  • Content Count

    427

  • Joined

  • Last visited

Posts posted by Coolcrab

  5. Posted · Edited by Coolcrab

    The paddle part was by bogax. It basically is a script that allows the telescope to point anywhere, with p the 'x' position and q the 'y' position of the end point of the beam. In his original script you could move the line anywhere and let it terminate mid air if you moved the pad0down. I changed it to move along the edge of the map. So it starts in the low right corner, moves up (in q) then reaches the upper left corner and moves right (in p) until it reaches the upper right corner and then moves down (in q)

     

    I didn't rename them because I didn't want to touch that script too much. But you could call p _telelescope_point_horz and q _telescope_point_vert. (Or something similar) [small side note, the edge of the field is not the same as the edge of the screen, there is about 1 block missing on both sides, can that be drawn in somehow to make the telescope beam touch the window edge?]

     

    And I have no idea what _blink is for. Probably something to do with the menu but it got replaced by something else. :P so yes that can go.

    • Like 1

  8. Posted

    The game modes. In the old version I had this on the right A/B switch.

    Gamemode 1 is a progressive game where the clouds change by adding +1 to NUSIZ1 and every 7th level the clouds become faster. (this should probably happen quicker). But its predictable in the way of what the next level will be.

     

    Gamemode 2 is more random. Each new level will have a random NUSIZ1 and place the cloud at a random speed and location. The star is also in a random location. So its a bit harder and less repetitive for people who don't wat the same level over and over again.

     

    ​I also wanted to add a difficulty setting on the AB switch that I freed up to make the star_int a bit lower and maybe give more points per star. So that it is more forgiving.

  11. Posted

    In the main loop score is used as a countdown. So at line 320 it ticks down and at line 414 it can go up. (when a star is observed)

    At 294 I say _level = _level +1 and count it that way and at 349 I replace score by _level and go back to the menu. (all in the 0.8 version that I uploaded last time.)

     

    Is that what you meant?

  12. Posted

     

     

     

    Some people might want to play it on an Atari 7800 that has a button instead of a switch, so the game wouldn't work properly on that console the way the program is right now. The example on the bB page works on the Atari 2600 and the Atari 7800.

     

    Aha I didn't know! I don't have a 7800 unfortunately. But in that case it is a good point indeed.

     

     

     


    I wasn't exactly sure what you were doing with the score. Now that I look back at it, it's just showing the level that the player reached, right? If so, that means only one variable will have to be used to remember, not three like the usual high score code on the bB page.

     

     

     

    Yes, ok then that won't be too heavy to implement variable wise. Did you manage to free any variables up by the way?

     

     

    batari had a lot of things on the page already, but more was added over the years. I asked a bunch of questions when working on Seaweed Assault and some assembly language programmers got together and came up with solutions for various things I needed in the program. I put their useful code on the bB page in the hopes that it would help other bB users who have the same questions.

     

    That is nice indeed. I love how nice and helpful this community is.

  13. Posted

    Let me know what you want and I'll rip out what you don't want or try to add or fix what you do want.

    1) int stands for integrate. So how long the telescope has to look at it to go up or down one block on the healthbar/observation bar. The star_int might have to become longer at higher levels. But then there's another thing to balance :P

     

    2) this does seem like a good solution and if it fits it might be nice to have. But requiring the switch to be in a certain position is not to strange is it? You have to also make sure the left and right switch is set properly.

     

    3) the idea was to save the high score. But if wouldn't give it the highest priority. My method should work though right? Because I compare the value that I put into the score with a different variable. And not the score itself. (That gets redrawn each time with bogaxes secipt) since I use the score for a countdown anyway and don't display the level until after the player dies. (Although it would be nice to show that somehow. But it seemed confusing to show the level in score and add a second Life bar that counts down as the timer. Input on that is welcome.)

     

    Thanks again for looking into this. And I really have to read your site more, as it keeps surprising me how everything is there. :P

  15. Posted

    In C if your code is this:

     

     

     if (slowdown - level) 
 { 
 // do something
 }

    Then do something would occur if the results of slowdown - level was non-zero. As such, in C using - is the same as using !=.

    bB might work the same, though I think bB uses <> instead of !=

    That's what I was going for.

     

    "If slowdown - level then " should be true shorter than "if slowdown then" if you are calling "slowdown=slowdown-1" every frame. But there are better ways of doing this now that I think about it. :P

  17. Posted · Edited by Coolcrab

    I finally found the place in your program that is causing a verbose error message for me and I don't know why you aren't getting the same error. Here it is:

       if _slowdown - _level then . . .

     

    Is that supposed to be an equals sign?

     

    Strange that didn't give me an error. The idea there was that the cloud will move slightly faster each level. Instead of every 30frames it would move every 30-level frames. But this gets very hard very quickly so maybe it should be removed (and put back into the if _slowdown check 1-2 lines below.) Making it progressively harder is difficult all together. Is there some general rule for how to speed things up properly?

     

    But odd that it doesn't compile for you. Ww should have the same bB now.

  18. Posted

    I'm going to see if I can squeeze out any variables and see what I can do about the other things.

    Thanks! :)

     

     

    I don't think you need seperate variables for the sprite positions

     

    This would free up 6, so that would help. You mean just using player0x, etc instead of _star_x right?
    I don't think any of the variables used by the line drawing needs to be persistent

     

     

    Yea you can use it for throwaway values. I used g in that way for example. But you can't store values in it right?
    If the astronomer doesn't move then those coordinates could be constants they currently get set from constants, the constants could be moved into the code and the temp variables used for something else

     

     

    Do you mean x1 and x2? They can't be constants right? It has to overwrite them when moving.
    I expect all that junk using p to fake paddles could be cleaned up or removed

     

     

    I like having both paddle and joypad compatibility, so I'll probably leave it in.
    Only three bits of f are used by the line drawing you could use the rest for state (it would need some code to seperate them when needed)

     

     

    That could work.
    You could maybe save something by taking your star/object velocities
    from a table indexed by some master clock you could also solve your
    stars going off screen that way (but it would need a variable so you could
    do fractional y velocities)
    It would be simpler and more straight forward, and arbitrary
    (you could add retrograde motion planets, or comets or something)
    but it might need more ROM (but maybe not much, you'd be replacing some
    code)

     

     

    How would you do this? I don't really understand how that would work with tables. (Although I haven't done much with it yet) I did want to put some meteorites in, and that should work by just freeing the movement vars. But what you describe sounds very useful.

  19. Posted

    I've added mode setting in the menu,more sounds and a high score option. But there seems to be some kind of bug with the score. As it is set to 5 when pressing select (changing game mode) and I am not sure why.

     

    Also sometimes a star manages to go up above the screen, while this should be prevented by

     if _star_x < 25 && _star_y > 1 then _star_y = _star_y - 2 : goto skip_move
 if _star_x < 50 && _star_y > 1 then _star_y = _star_y - 1 : goto skip_move

    If you guys could take a look, that would be great :)

     

    Apart from that I'm running out of variables to do much more, are there any more that I can use other than a-z? Otherwise I'll have to check what I can resuse where.

     

    After this is done, I think that I have Incorporated all feedback so unless more will come (Especially longplays would be great as I don't know if the difficulty increace is fair) I think that it's mostly done.

    astronomerV0.8.bas

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...