Streaming the raw YM-2413-commands directly works well, and is as optimized as you can get it :-) Thanks to the megarom-format I am able to fit all the data into the game... -music data wins the competition when it comes to storage requirements 
Awesome! As you know I’m also a fan of this type of music player . It’s very CPU-efficient. Glad to also see it work out for others. Did you look more into compression, or are you like nah it works, plenty of space, waste of time? For me, although I’m still definitely interested in researching the topic more, it is quite a complicated subject, and since it works fine without it doesn’t block the game project.
TLDR; For the time being, I haven't followed the compression-idea
Although the topic is super-interessting, it would take time for me to look into. So I have devoted time on other things in the game and in the music player in general. Once moved to megarom-format, I found that space has practically no limit.
The only limit is that things are put into chunks. So, as I have chosen ascii16 (16kB segments) and I have also chosen to keep (re-) using only one page for the music, I need keep track of when a tune crosses the page-bounds. This could have been done with an indicator in the stream itself - this comes with its own issues with encoding, "segment-fill-percent", 16Kb-aligning, preprocessing and such, so I chose another way.
I have chosen to check for boundary for every byte I read from the "stream". Sounds excessive, but we *must* wait once first, 12 cycles ("register"), and then 84 cycles ("data") for the other register-write anyway (totals 96 for any data-pair written)... --I thought, why not spend these cycles on something sensible instead? So, I managed to get the code checking for bounds down to 12 cycles + 85 cycles (respectively). (actually I got the last "wait-code" down to 83, but we cant' use that). Once page/segment-bounds are reached, I just increment the segment-number as I always store music-data in sequential segments. All this makes the player flexible with regards to data-storage or data-preparations.
Also, I the case of any compression, it would likely add some cycles to the player. The compressed data (which is more like redirecting your current pointer here and there) would have to keep track of points/addresses to jump to in the stream. And these would need to include segment-information. I assume some overhead on this, and I don't think I can afford that in this particular game. With compression the cycle-cost seems a little less predictable, than plain raw streaming. Another thing - Wolf isn't exactly using the simplest instruments , so the amount of data written to the registers are quite high at times. I think on average the player uses around 1000-2000 cycles with a normal peak of 4000-5000 cycles, but I've seen as many as 82 register writes in one (tune start-up) frame, recorded from MoonBlaster. This would give a minimum of 82*96 = 7872 cycles in any player. Could be that the data MoonBlaster writes to the chip could be optimized, as it does write several times to the same registers during that same frame. I'm not sure, at this point I have no knowledge - this is down to YM-2413 details.
Another thing that doesn't come easily with a raw-player, is the ability to fade. So, there we have another issue, how to handle that and at the same time keep the cycles down at 96 cycles pr data-pair-write
So, no, kept the compression-idea off, for now
I've made some new footage
This time from the theme "Shoreline". Some of you have seen the style before, but there are new stuff and many improvements "under the hood" added, as well as music from Wolf which I think fits perfectly. I did the footage in 50Hz this time for the single reason to show how the pace is in PAL. I actually think 50Hz is closer to what I find ideal for this game. The 60Hz is a tad too fast, but it is hard to get it perfect for both.
The only limit is that things are put into chunks. So, as I have chosen ascii16 (16kB segments) and I have also chosen to keep (re-) using only one page for the music, I need keep track of when a tune crosses the page-bounds. This could have been done with an indicator in the stream itself - this comes with its own issues with encoding, "segment-fill-percent", 16Kb-aligning, preprocessing and such, so I chose another way.
Ah, that is what I did . It wasn’t too much hassle to let the build script insert it. The same “jump” command (taking segment + address) is also used for looping.
I have chosen to check for boundary for every byte I read from the "stream". Sounds excessive, but we *must* wait once first, 12 cycles ("register"), and then 84 cycles ("data") for the other register-write anyway (totals 96 for any data-pair written)... --I thought, why not spend these cycles on something sensible instead?
True that! There’s a fair amount of time considering that you need to wait anyway.
Another thing - Wolf isn't exactly using the simplest instruments , so the amount of data written to the registers are quite high at times. I think on average the player uses around 1000-2000 cycles with a normal peak of 4000-5000 cycles, but I've seen as many as 82 register writes in one (tune start-up) frame, recorded from MoonBlaster. This would give a minimum of 82*96 = 7872 cycles in any player.
For my player I have made a dummy track for testing which writes to every register in the span of two frames. it takes max 5715 cycles per 1/30th of a second. I thought this would be a sensible maximum under the reasonable assumption that not all registers will change twice within that time, and it allows me to test my game’s performance under continuous maximum music replayer load.
Another thing that doesn't come easily with a raw-player, is the ability to fade. So, there we have another issue, how to handle that and at the same time keep the cycles down at 96 cycles pr data-pair-write .
Yeah, that would require to cache the last written register values, and to always subtract an attenuation value from the volume registers (and update all when volume changes)…
p.s. I think I’ve said it before, but it’s looking and sounding real nice!
This approach may be well suited for fm-chip playback, where most of the time the updates are focused around note on, note off and frequency. For PSG and SCC music there is lots of volume updates to handle as well (since ADSR is not done by hardware) which can generate loads of extra data.
Well still MegaROM space is near infinite, and there are less channels so it’s not too bad. The 18-second Corneria Castle track from Final Fantasy takes 5886 bytes, and the 41-second Town of Nemnu from Xak is 28412 bytes. Micro Cabin works the PSG and FM pretty hard so there’s a bunch of register updates each frame especially in the latter one.
But yeah compressing even in the simple form of storing instrument data (such as SCC waveforms) separately so you can update waves with a single indexed command will save significant space without having a large impact on performance.
Looking very very nice
I love it! How do I get my hands on this game? Is there a physical copy I can buy?
Thanks foody! The game will be out later next year, and there will be a physical copy for sure Cover art is being worked on as we speak. I'll publish it myself or possibly use a publisher if I'm convinced that that is a good solution for me and the IP.
