Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Sprybug last won the day on August 4 2013

Sprybug had the most liked content!

Community Reputation

482 Excellent

About Sprybug

  • Rank
  • Birthday 08/01/1976

Contact / Social Media

Profile Information

  • Gender
  • Interests
    Professional Character Animator

Recent Profile Visitors

16,104 profile views
  1. Sure. Have you tried messing more with the code to try and do other things with it?
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Yep, learned how to use Nibbles, so I can implement some more things.
  11. 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.
  12. 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.
  13. 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!
  14. 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.
  • Create New...