19th of April puzzle completed

More than two weeks without a post about Release…

Well – it isn’t that I didn’t do anything Release related – but the things I did were not ALONE Release related.

I did many things music related. As the last post suggested I was slowly running out of ROM/RAM space. And although I thought about it before I never felt the nessessity to actualy do it, build a: Arkos player for vectrex.

I documented the work on the Vide blog, but the aftermath of the construction – for now at least – is Release conversion.

The time consuming work to migrate the music pieces to an efficient YM format was wasted – and I now can play music pieces “directly” without having to go through the “expensive” YM format.

The resulting ROM space will be easily filled. Probably there will be several pieces of music, as of now I think about:

• Title music
• In game music
• Highescore music
• Game over “jingle”

I have to see how much time and good will vtk has left :-).

Some more technical “crap”:

To be most efficient I used two different Arkos player versions within Release:

• in game
  That version plays only one channel (and also only decodes one). At MOST (!) this small little darling uses up to 600 cycles.
  The “average” is not realy mentionable!
  The old ym player in game was realized as 6 different little routines which were optimized and were called in long “moveto” phases. All that good old optimization gone to waste and thrown into the bin. Thats! – what development is about :-)!
• not in game
  That is the normal player with all features – as noted in the other blog max cycles about 1700 but averages about 700 cycles.

After throwing away the old music and old YM-player stuff there was no ROM space problem left anymore – only thing… RAM.

By now I didn’t have much RAM left (perhaps 5 bytes…). So I got thinking and changed a whole lot of code.

The bottom line of what I did is:

Reduce the Object structure by two byte:

The TYPE is gone and the DDRA is gone.

Both resulted in rather large code changes – both changes at the cost of a few cycles – but that could not be circumvented.

The thing is I really NEEDED the type, it is used to:

• identify friends and enemies
• for the collision detection (dragon can be hit twice)
• and other things

As you see the definition of TYPE is still there – but without a byte attached. I now use the first byte of the behaviour subroutine as identification marker. I made sure that each behaviour routines starts on a different page boundary. I also made sure that all enemies have page boundaries below $6000 and all “friendly” objects (stars, bonus, scores…) have page boundaries above $6000.

With that a unique identification is still possible.

This may all seem like peanuts stuff – the thing is, in a tight knit game so many things relate to each other. For example the starfield now internally is realized quite differently than before, since as mentioned the starfield also is an “object”. An object which consists of 4 stars, each star used to have a 2 byte position – which was not possible anymore (2 bytes less). Now each star actually has all position information crammed into a single byte – AND has also the ability to “swirl” (which it couldn’t do before).

Anyways…

Release uses by now 40 objects. With two bytes saved for each object I have salvaged precious 80 bytes of RAM. The Arkos player uses 74 bytes of RAM – hurray!

I used 2 bytes to enhance the demo mode a little. Also the “volume” of the SFX is now configurabe (well, full/half/none). Three of the four mentioned music pieces are (mostly) inserted. All pieces are very good – but I especially like the titlesong. For it to be playable in one piece I expanded the scroll text 🙂 – so the demo mode does not jump in so very “fast”.

Thats the state now.

More testing… going on.

Malban