Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Sprybug

  1. Yeah, when I figure something out and have to explain it, I tend to throw assumptions that you might already know a few things. Really what I posted was more of a guide, then straight up code, on how you can setup some variables, in this case nibbles, and bits to setup an environment for your game that you can use to move your player around in. When you have it, you can program how you interact with these values to change how your player moves in the game environment.
  2. Just gonna add my 2 cents here, since I have momentum in my games, and will be doing an ice level where it will be slippery. In Zed, I figured out how to do Nibbles. I use one nibble for gravity and one for momentum. So, it just takes one byte for all momentum controls and a few bit flags so the program knows what state your player is in. For the Zed control bits, I have these: dim Zed_Flags = d dim Extra_Bits = g rem Bit Definitions def Zed_Direction = Zed_Flags{0} def Zed_Jump = Zed_Flags{1} def Zed_Hit = Zed_Flags{2} def Zed_Shoot = Zed_Flags{3} def Shoot_Debounce = Zed_Flags{5} def CP_Debounce=Zed_Flags{6} def Music_Bit = Zed_Flags{7} rem Enemy Direction 0 = Facing Right | 1 = Facing Left def Enemy_Direction = Extra_Bits{0} def Ball_Direction = Extra_Bits{1} def Missile_Direction = Extra_Bits{2} def Section_Exit = Extra_Bits{3} def Zed_Turn = Extra_Bits{4} def RetOTBank = Extra_Bits{5} def Temp_Bit=Extra_Bits{6} def Genesis_Controller = Extra_Bits{7} As you can see, I have one bit set for the facing direction, one for when he is jumping, one for when he gets hit by an enemy and is temporarily damaged, one for when he's shooting, and another I made as an addition to help the controls not be so touchy for turning, meaning that he stops, turns (shows the turn sprite for 1 frame), and then faces the other direction before continuing. To setup Nibbles functionality, do this: macro _Set_Lo_Nibble {1}=(({2}^{1})&$0F)^{1} end macro _Set_Hi_Nibble {1}=(({2}*4*4^{1})&$F0)^{1} end rem Momentum and Gravity dim Gravity=n def PEEK_Gravity=Gravity&$0F def POKE_Gravity=callmacro _Set_Lo_Nibble Gravity dim Momentum=n def PEEK_Momentum=Momentum/4/4 def POKE_Momentum=callmacro _Set_Hi_Nibble Momentum In order to not fall through floors or jump through ceilings, Gravity can never be above 6, so it works perfectly as a nibble. Since I scroll, momentum is never above 4, which again makes it perfect for a nibble. When you jump, the jump flag is set and Gravity is set to 6 to start him off fast in the air. Then every game cycle is decreases by one until it hits 0. Then the flag is turned off, and I let my platform check routine see if he's on a platform or not, because if not, then he'd be falling and then gravity starts increasing by 1 until it hits 6 (terminal velocity) or he's on a platform. Of course to set it, it'd be: POKE_Gravity 6 To decrease for example you would temp4=PEEK_Gravity temp4=temp4-1 POKE_Gravity temp4 Then of course you would player0y=player0y-temp4 for jumping (+temp4 for falling and you would also increase instead of decrease the count). It gives a good sense of gravity and a nice arc to your jumps and falls. Momentum works the same way, except it's controlled by your left/right joystick. It gets set to 1 once you start moving, and then is added on if you continue moving until the maximum is 4. You do the same in that part of the routine. POKE_Momentum 1 then later when it's appropriate temp4=PEEK_Momentum temp4=temp4+1 POKE_Momentum temp4 and of course when you let off on your joystick, you would decrease it 1 by 1 until it stops. Thus, player0x=player0x+temp4 or -temp4 depending if they are facing left or right, which is where that direction flag comes in. Once you have all that set up, you then have a system where you can play around with your game's environment. So, when I make my ice level, the game checks that hey, we are on an ice level, so let's have him slide, and then all you would need to do is when the joystick is let up on and you still want him to keep sliding, you would countdown Momentum to just 1 and stop there. That would cause him to move 1 pixel (on a non-scrolling screen) until you turn him around or however you would stop him.
  3. I've finally finished the after level menu system and wanted to show it off and let you play around with it. I have given you all the robots you can rescue to switch powers with. I can't test the save feature since I do not have an AtariVox, nor even if I did, a way to test it through emulation. When I try it, it just locks up the game. However, when I remove the file init part, it will pretend save, so if anyone out there has an AtarVox that you can run through Stella, please let me know! For now, it's just going to lock up on you when you try to save, so best not to choose it right now. The game will also crash and reset after the title screen for the level you chose appears, because the levels have yet to be made! This is the next part I am going to work on. Enjoy! RobotZed_15.bas.bin
  4. Sure. Have you tried messing more with the code to try and do other things with it?
  5. Hey, saw the link to my topic. I just wanted to let you know that I did implement a new sound system on my game, however because of RAM limitations, I only had 3 bytes and a bit to my disposal and what I wanted to do originally required a bit more than that. So I decided to take the typical method and streamline it a little. This method actually will reduce the size of data in your music sequence. For example, I cleared up 1K of space using this method, for the Base Area music in Zed. The original data method for music is like this: First line is channel 0 AUDC value, AUDF value, AUDV value Next line is the same except for channel 1 And the last number is the duration in frames (or game cycles in my case), that this gets played, or the 255 terminator. Well, I quickly figured that there was a lot of wasted space going on here, when all you want to do is, for example, just change the volume level, but keep the same C and F value going, because there's no reason to change the registers. The old way we had to repeat it, thus wasting bytes. But with this method, we can cut out the C and F, if there going to be the same, and just alter the volume instead. What we do is, if we're repeating the same C and F and just want to lower the volume, we'd replace the first value with a volume level above 15. The Atari's volume registers go from 0-15. If we go higher than that, then we just tell the program that this is just a volume change and don't bother with C and F. Then we subtract the volume level by 16 to get the true volume. Example, 16=0, 17=1, 18=2, etc. After that we skip to the next channel read and see if it's doing the same thing on channel 1 or not that we just did with channel 0. To get an idea of what I did, here's an example from my new Base Area music data: And so on. This is the first measure of the song. First line we have all the info, since it's the beginning. Channel 0 C,F,V, Channel 1 C,F,V, duration Line 2, is just read as Channel 0 volume 6, Channel 1 volume 2, duration Line 8 is setting just the volume on channel 0, while setting up the new sound for channel 1. Channel 0 volume 7, Channel 1 C,F,V, duration And you can also do the reverse as well (Channel 0 C,F,V, Channel 1 volume X, duration) And a 16 you can use as silence on the volume change After doing this on the Base Area song, I ended up saving 1K of space! The bit is used to detect if a sound effect (thus canceling the music for channel 0), had just finished playing and to silence channel 0, until it can load up the next new sound on that channel. Here's my code on it: Music_Bit is a defined bit I made from Zed_Flags{7} (Notice I had to use this later because there is a bug when conditionally checking a not on a bit that's been defined, so I have to resort to using the original name), and Sound_Effect is a dim I did for the Sound_Effect value to play in the Sound Effect routine. Checking this to see if it isn't zero means that a Sound Effect is currently playing. Music Bit being 0 means that a sound effect finished playing and to silence this channel until the next sound register can get loaded up (this is set in the Sound Effect playing routine separately after it plays a sound and sets this bit to 0). Notice that it sets the bit to 1 once it loads up an actual sound. It does this regardless if the bit is 1 or 0. This makes the music program play normally again. So, I use p as my duration, q and r as my sdata pointer, v for my sound effect pointer (if you use this method), and a bit to determine if we should silence channel 0 after a sound effect until we can load up the next note.
  6. Would love to do that one day, and maybe after I finish Zed. My focus is finishing Zed, although I am taking time to develop this "kit" just because it'll make it easier to make the other music for the other levels, and slim down the ROM Space it uses. The music that plays at the "end credits" of Zed that you hear, takes about 3K of ROM Space. With this system it'll take less space, because I can just have it repeat and jump to certain patterns with a pattern table that can hold 16 patterns, and not just have to have the data duplicated again in the standard engine method, which quickly eats up ROM space. After Zed, I would love to make a MIDI cable device that could hook up through the Atari's Joystick port and then hook up the Midi in/out end to your keyboard. Then have a cartridge you could plug in, to compose Music with your midi keyboard straight into the Atari. Then you could use the 2nd joystick port to act as a serial interface with your PC'S USB so you can save the data to a file using a front end program that will run and capture the data to save as a data file for the Atari 2600 cart, and a text file that you can copy and paste and use in the Batari BASIC music engine I am developing, but that's all a pipe dream.
  7. Thanks RT, I'll be sure to change that on mine, although I am still using Win 7. It sounds like the new version uses .script regardless of what OS you have. I use this feature to make sure I'm not going over cycle count on Zed.
  8. Currently developing the engine. I decide to do some more tweaking, so I could have more control over the volume decay, which of course added a whole other byte (2 Nibs) because of the two channels. Sure, it's now taking a touch more memory than the standard, but the features, ROM space saving space, and the easing of implementing music makes it worth it. I will release a stand alone engine and a tutorial for it in the near future.
  9. Actually, nope! Still doing Batari. Just figured out the whole nibble thing by reading the tutorials and trying it out. I always try to squeeze the most bits I can out of this thing. This means that other people who use Batari will be able to use this code and format in their own games to make it easier to add a soundtrack. Now, of course it's not going to write the music for you, but if you know a little musical theory, this can go a long way. The Sound effect maker, I'll be writing in DPC+ to take advantage of the higher resolution and multiple sprites. You'll just have to write down the values it gives you on paper or something and then put them in a data statement for your sound effects. I could release how I handle that too. It's really simple actually.
  10. Yep, just as I expected! I needed to have the decay set up for both channels, so have to add another nibble and byte for that, but still in total that's 2 bits less than the standard method! Plus it's more compact and takes less ROM space for your music data, while implementing some nifty features. Let's see if I can get this working.
  11. Just wanted to let you know, I'm developing a new music engine for Zed, which I'll make available to anyone who wants to include it in their game. It allows use of Patterns (Up to 16), so you can easily repeat sections of music (Save ROM Space!) Each pattern can hold approximately 5 measures of music (4/4 Time) Data for the measures is only inputted when there is something to spit out, which saves even more on ROM Space. Ability to jump to other music patterns out of sequence. Ability to loop a song. A databank that sorts the Atari's musical scale to make it easier to input the data. A special bank for drums and percussion Ability to hold a note, a natural sustain decay, a slowed sustain decay, or cut a note. And all this I was able to do using only 2 bytes of RAM and one extra bit! It takes even less RAM (by 7 bits) than the standard way of doing music in your game via Batari! A sequence pointer that is one byte, a pattern pointer that is one nibble, a volume control nibble, and a toggle bit for slow decay. It does use some of the temp variables, and a few of my own variables I use as temp variables (I need them to last for the whole routine), so be sure to have a few extra bytes handy for those. When I release it, I will also release a sheet that shows the values of the notes on a keyboard, along with the sequence values for note holds for 20,30, and 60 FPS games. The notes will also include the best key signatures to use for your games, because of Atari's limited musical scale. After this, I am going to start work on an actual Atari 2600 program where you can play around with the TIA to experiment on making new sound effects. It will show you the values you are using in the interface, so you can write them down and be able to put them in your sound effect data sequences. Now of course specs can change because I might have originally overlooked something, which knowing myself, is highly likely. Like for example, right now, I'm wondering if I have to add even more bytes because of the simultaneous channels doing their own thing or not. I just finished the program and yet have to take it for a spin, so I'll keep you posted.
  12. Thanks David. You know, I think you're the second person to tell me that they were hoping to run into me at a PRGE event, recently. I wonder, next time I attend, if I should put a huge nametag on my shirt or something, because I do hang around the AtariAge booth from time to time while at PRGE and am always happy to talk and meet you guys.
  13. Yep, learned how to use Nibbles, so I can implement some more things.
  14. Not a requirement, but preferred because that's the primary language, and I'd like to be able to speak their primary language living there.
  15. I'm glad you are streamlining it, because for you and your wife, it was just a ridiculous amount of work. Glad we could help break down your booth though at the end. Yeah, I wish I could be there and I wish Zed would be done in time. You will have a new demo for sure because as you've seen, the latest demo is out and it has a boss battle. By PRGE point, I would like to have the updates to the engine for better controls, fine tuning, non-farming, and perhaps a better system of powering up using sprites instead of missiles.
  16. lol, no but I need to learn French, because it's the French-Canadian part of Canada, oui. And don't forget poutine. It's big in Quebec. Will have an ample supply of that!
  17. Thanks. I know you were debating it this year yourself. Yeah, there is no way I'm going to be able to attend, I'll still be settling in to my new surroundings! Gonna miss PRGE for sure though. I attended it every year since 2012.
  18. You know, I completely forgot about the "extra variables" when you don't use certain features in Batari. I took advantage of those in Zippy. I'll see if I can find any spares that I can use to act as my level progress pointer to stop people from farming power ups by continuously spawning the same enemy over and over!
  19. Actually, native Washingtonian and resident of Oregon for the last 11 years. I lived in Vancouver, BC for a year when I went to VanArts. Got my passport submitted and expedited, now just waiting for it to come in, and once that comes in send the ID to the studio so they can send me another ID to use with a Canadian government site to login with to get my work permit processed.
  20. Thanks guys. Just giving an update! I figured out how to do Nibbles! So, this is going to allow me to add some better play control by adding momentum moving left and right, so the controls aren't so touchy! I need to start implementing nibbles because I am out of RAM, so I am going to split up what I can. I have several variables that never go over 16, so I'm wasting valuable bits! Not sure how much I'm going to be able to work on it the next month and a half because I got a big announcement. I got a great new animation job at a studio in QUEBEC, CANADA. I AM MOVING. So I've been very busy working on my move, learning French, and working with them remotely in the meantime. I plan on moving there next month. I am so excited....and nervous!
  21. Yeah, this one isn't an exact clone of any game actually. It take elements from other games like Kirby and Mega Man for sure, but add a rogue like element to it all and you get Robot Zed.
  22. Talking this out with you reminded me of something. After the demo, I was going to go back and start changing a few variables that only use values 0-16 and splitting them in two, making them essentially 2 nybbles. The reason why I mention this, is because I have already used all my ram. I have one variable that is for gravity momentum when you fall or jump. It never exceeds 6. Make that a nybble, and then I can use the other half as another momentum nibble for starting a walk/run. When the screen scrolls 4 pixels at a time, there's nothing you can do about it. You're locked at 4 pixel movement. HOWEVER, if you're still and you're just starting to move, the screen will not scroll, so you can build up a little bit before you take off again. Looking back, this is how Princess Rescue worked, and it worked pretty darn well then, I just have to go back and make quite a bit of adjustments to the code to make this happen. This should help give it more of a Princess Rescue movement vibe. Not exactly, but close.
  23. Good suggestion, and like with Zippy, I'm doing 2 screen draws for every game cycle, already putting me at 30 FPS. I split the two so I can fit in more CPU cycles to do more things. Princess Rescue used 3 for 20 FPS, but since then I was able to refine some things. The only downfall with your suggestion though, would be a noticable speed down and speed up every time you moved, which would also mess with the speed of the soundtrack. I've been thinking about using a bit to make your increments 2 pixels instead of 4 when you start moving as a momentum buildup, and then when you move twice under that you go back to a full 4, keeping your increments even. It shouldn't throw off my platform checks and it won't do a screen scroll, which by in of itself eats a lot of cycle time.
  24. Haha Haha! I was playing it yesterday and trying to break stuff and the same thing happened to me, but it just advanced me to the next part of the level. You were probably just one level away from getting to the boss already at that point. This is one of the bugs I'll need to fix.
  • Create New...