EricBall's Tech Projects

Hi there!

 

My recent drivers are pretty compact.

Seawolf uses 97 bytes of code and 238 bytes of data.

Crazy Balloon 82 bytes of code and 105 bytes of data.

 

The Seawolf driver is a little more complex, because it's data is structured 3 levels deep. (using sequences made of sequences made of sequences)

 

Didn't comment much on yours, because from my perspective you were just re-inventing the wheel

 

Especially your data format seems to be pretty unreadable, while my tunes are constructed of small data sequences using music.h, looking like this for example:

 

D1_02

.byte #SAW_G2_1

.byte #LEAD_H3

.byte #SAW_D2_1

.byte #LEAD_H3

.byte #SAW_G2_1

.byte #LEAD_H3

.byte #SAW_D2_1

.byte #SAW_E2_1

 

Greetings,

Manuel

You've got a working kernel that isn't going to have to change much, right? So what I suggest (for now, for simplicity) is to modularize your code so that each level is to be stored in a separate multiload file.

 

Create your standard template for a multiload level file and generate 10 test ones.

 

For UI, let's say holding down select moves forward one level and holding the fire button down while you press select moves back one level. Holding select and reset moves faster (like in Space Invaders. This would just update the level digit display. When you get to the number you want, the actual load wouldn't queue up until you push up on the stick or something.

 

When you press up on the stick, it jumps to the Supercharger loader for that particular level.

 

If you can do that, let me know because I'd like to take the sourcecode and wedge in an autoloading system based on shooting load requests through the 2nd controller port to a PC serial port.

 

I know this can work. I just need a sample program to test out the theory and I've been waiting for your code to get far enough along before I asked you about it.

 

If we can do this, then all future 1-player Supercharger games will be able to random-access autoload their multiload files with a cheap cable, a PC, and a freeware terminal program and a Supercharger or Cuttle Cart (Cuttle Cart 2s already autoload from Flash).

 

Sound cool?

Hi there!

 

Sound cool?

 

Even cooler than random-access sounds explicit-access. Then you could for example load the rooms for Impossible Mission when you need them

 

Greetings,

Manuel

The idea sounds intersting, but I am not sure what makes this a "tracker"? As Manuel has already noted, it looks just like a regular music file player? In my experience, a tracker usually works by multiplexing sound samples, so I was expecting something using "soft synth" techniques. However, I could be missing something here?

 

Chris

Manuel, you are, unfortunately, correct; now that I think of it. Just a slightly different way of doing what has been done before. Not even necessarily any better. And you're right that equates would make it more readable. Maybe something to consider for Rev 3 when I have more time.

 

Glenn, it's always been my intention to have Leprechaun multi-load. Basically each level would be 1K of data containing the background bitmap and other level data. The rest of the code would remain the same, including some kind of level select screen. However, I'm not to that point yet. My primary focus is on getting the player & enemy movement logic down.

 

Chirs, tracker in the most simplistic sense of playing a sound track, versus the various MOD-style trackers which could play samples back at various rates to mimic instruments. Unfortunately, the VCS doesn't have the horsepower to do this without a Pitfall2 style coprocessor.

One thing I'm not happy with is the byte to note ratio being 2+. This chews up ROM space much faster than I imagined. Certainly with a lot of repeated sequences, the total bytes per song will come down, but even my demo takes 168 bytes.

 

Which kinda puts my idea of dedicating a page of ROM in Leprechaun for music to be woefully inadequate. I could probably come up with a data format which would lower the bytes/note (since I'm using one whole byte per note to store length), but it would be more costly in code space and would certainly need at least a byte more RAM.

Music just chews ROM, no question about it.

 

The "problem" with your music tracker is that it accomodates everything. Every possible produceable sound. If you can figure out what sounds you need, then you can start cutting things down...

 

In Go Fish! I used 2 bytes per note:

First byte: VVVLLLLL - 3 bits indexing into a volume lookup table and 5 bits of note-length data, in 1/60th of a second (i.e., my music driver updated every frame).

Second byte: ASSPPPPP - one bit of articulation data (i.e., 1 = slur the note, 0 = articulate the note), two bits of sound-type data (I used square, lead, noise, and bass distortions only) and 5 bits of pitch data.

 

I used five and a half pages for music data, but I really wanted a LOT of music.