MB-Wave (Was: games)

[Arjan Bakker]

MtH wrote: >If the size of the song exceeds 16K, fitting MBWAVE music in a 128K game >will become very hard. And maybe 2 bytes is optimistic, it could be 3 >(because you also have to store the sample number). Yep, that's right. You need 15 bits to store the frequency and 9 bits to store the tone-number. That's 24 bits = 3 bytes. The songs would become very large this way, but this doesn't neccesarily have to be a problem.   LH wrote: >Also, I think that if the music data is formatted the right way, it >shouldn't be too large. I don't know exactly how MB did it, but I bet it can >be done better. What I recall from KousTracker is that the musics really had >to be extensively large before they would exeed 16k (in fact, they even >couldn't exeed 16k). I don't know how KousTracker stores music, but I think MB stores it pretty efficiently. An empty pattern takes 64 bytes (including CMD-'channel''). All extra events only cost 1 byte extra. In the system you suggested (notes seperated by length-bytes), you will need 24 bytes in order to know the offset of all channels, plus 25 bytes for each channel in order to know when the next note will be played. That's 49 bytes in total for an  empty pattern. But all events will use 2 bytes. Let's calculate the amount of events for which the MB-way is more efficient. 64+x = 49 + 2x so when you have 16 event, the MB-way is more efficient (but slower)   >There's a point. Are you talking about the P+1 thing??? I think simply >increasing the frequency will suffice. In fact, MBWAVE also does this, since >I hear no audible 'steps' in the pitchbends. That's true, pitch bends are not a problem when you want to store the frequencies instead of notes. But linking notes is, because the difference in frequency differs per tone and also per linking distance. So when you want to link notes, it's impossible to store frequencies instead of notes.   But I have to tell you something: calculating the frequencies doesn't use the CPU as much as the actual playing of the notes. MB-Wave divides the actions in 3 interrupts (when something has to be played, obviously not when use have a song with TMP1). In the first int it decrunches one pattern-row and calculates the frequencies for 50% of the channels. In the second int it calculates the frequencies for the other 50% of the channels and in the third int it plays all notes and events. The third int uses the CPU most (35% vs 25% in other ints), because playing notes is divides in 2 parts in it. First it loads all tones which have to be played, then it has to wait until the OPL4 has loaded all tones correctly (you can't change sample-headers when the OPL4 hasn't loaded the tones yet - not when you want everything to sound right :) ) After that, it plays the actual notes (and other events). The replayer changes the sample-headers in this part, which also costs extra time (but the time used differs per tone)   I changed the replayer a lot when I wanted to implement it in the FD. The original replayer could only play 12 channels, while the one we use know can play 16 channels without too much slowdown. My replayer now has a CPU usage of about 25% per int. The new replayer includes a routine which copies the sample-headers of the tones used in the songs to SRAM and changes them. It replaces the original tones in the patch-table by the new tone-numbers, making sure the correct tones are played. Also note that the ROM doesn't have a cymbal in it, it's a reversed cymbal, just with a different sample-header. So you always have to change this tone. This way the third interrupt is WAY faster because it doesn't have to wait until the OPL4 has loaded the tones and it doesn't have to change the sample-headers. The only things that costs some extra time is starting/stopping the songs, but that's usually not a problem.   You can get the replayer if you want it, but it's not a fully functional replayer. It lacks base-frequency support, it can only handle the standard values of the X-command, and it only supports 2 frequency-tables for own samples (8363hz and 22050hz). The .MWK-loader is seperated from the replayer, so you can kill the .MWK-loader after you have loaded a sample-kit. Also in my replayer you can change the number of channels CORRECTLY, the original messed up with it when you use pitch bends. You also can change the maximum of own samples you need, because the replayer uses the tone-headers that are not used to replace the original ROM tone-headers. It's currently set at 16, which is usually enough.   If you the replayer, just mail me and you'll get it.   Arjan