|
Post by turboxray on Aug 6, 2023 9:28:51 GMT
|
|
|
Post by turboxray on Aug 7, 2023 3:38:08 GMT
farMemcpy_v3.zip (2.64 KB) Added some additional support for temporary offsets (doesn't modify pointer), Examples give in the C file.
|
|
lunoka
Gun-headed
Diving into retrodev
Posts: 55
Homebrew skills: art, music
Fave PCE Shooter: Burning angels
Fave PCE Platformer: Ninja Spirit
Fave PCE Game Overall: Valis 3
Fave PCE RPG: Neutopia
|
Post by lunoka on Aug 7, 2023 7:34:39 GMT
Excellent, thank you!
First tests on dummy files seem to work accordingly, no problem with bank overlaping files. Plus performance seems to be similar to farmemget() sdk function. I will merge it to my driver and test on a real case to play several tunes in one rom.
|
|
|
Post by turboxray on Aug 7, 2023 17:50:28 GMT
I kept this example pretty generic (and slow), because I didn't know the exact interface of your binary parsing routine. It definitely could be sped up with a variant that has persistence in the far pointer (reserved address vectors). As in, every time you call - you don't need to do "effective address" calculations every time... the far pointer self increments based on size request and persists. That would gain some speed. A single "get a single byte" version could also speed up (depending on data structure where you need to read a byte to get a length or status first, before reading more or not). Could also speed it up with a Txx copy loop instead of an indirect byte copy loop.. when you know you need something like 32bytes from far pointer location.
|
|
lunoka
Gun-headed
Diving into retrodev
Posts: 55
Homebrew skills: art, music
Fave PCE Shooter: Burning angels
Fave PCE Platformer: Ninja Spirit
Fave PCE Game Overall: Valis 3
Fave PCE RPG: Neutopia
|
Post by lunoka on Aug 7, 2023 20:06:52 GMT
Well, here is simply how I work on my song files : - I read a 20 byte header fed with some information on the tune, the offset & size of the incoming instruments block, wavetables block and patterns block - I made the choice to load in RAM my instruments & wavetables, instrument format is actually 73 bytes long ( 2 envelopes ), (mutualized ) wavetables of course 32 byte long. 2 simple loops feed 2 arrays with fixed length ( 10 , arbitrary ). After that, the 2 speeds written in the header give the pace even/odd in frames for reading each line of my patterns ( tracker format ). Basically a track cell is written on 2 bytes. 4 bits for the instrument, 4 bits for the channel volume ( bit shifted to 5 bits when poking register 804 ), 2 bits for simple panning L/R and 6 bits for the note ( roughly 5 octaves available ), no FX tracker management but it could be done on a third byte ( maybe later for at least portamento up / down ). So it means I only read chunks of 12 bytes at a time when playing my tune for all 6 chans. I've also added a very simple 0xFF marker on first byte to remove empty lines ( often the case in tracker format ). I can easely gain 40% on the filesize with this simple method. 2 envelopes are managed for the instruments, the volume and the tone. The tone can be a pitch one or an arp one, very useful for SFX design in Furnace. The size of the envelopes is also fixed at 32 bytes like the wavetables. For the SFX, on the other hand, I read another sfx binary bank file containing all the sfx for the game, on demand since I don't know how many sfx I can have on a prod and it would be a waste of ram to keep them all in memory. Maybe I could do the same with the instruments but I don't have many xp on creating a sound driver so it's try & error. And I don't want to abuse from reading resources from the ROM during the frame but maybe I can have more latitude, it's all new to me. So one treatment is called at speed A/B time for reading the notes and another part is called every frame to update the envelopes. This second one is the one I try to optimize by unrolling my code. Last time I did this, I was around 10% CPU load for a tune. Considering it's made in C, I think it's acceptable and I can live with this and follow on other stuff to do. My main goal was to have a simple driver with a decent footprint on the files ( around 5KB each ), in order to remain usuable for a 1 MB hucard limit. And of course in C since I want to keep my projects portable ( the progression curve on learnin ASM seems harsh for now, maybe when I'll get retired ^^; ). I hope you have a better vision of my project nothing fancy, just keeping it simple and usable. I'm more interested in visual & audio making to be honest but working on the code part is also very interesting.
|
|