sverx
More compact storage of SFX channel status and other flags?
At the moment one byte per SFX is used to store the "in use" flag, but those can also be stored as bits in a shared location.
I reused the bit definitions of SFX_CHANNELx, so PSGSFXPlay can even set the variable directly. This saves 3 bytes.
Next I will probably try to save 3 more bytes by also defining bits for the flags below, but I was wondering what you thought of that, and if this is a change you would accept.
- PSGSFXStatus
- PSGMusicStatus
- PSGSFXLoopFlag
My project has become extremely tight on RAM, even shaving 6 bytes makes me happy... yes I'm in trouble.
My project has become extremely tight on RAM, even shaving 6 bytes makes me happy... yes I'm in trouble.
:astonished: :astonished:
so you'll not be happy to see that I'm going to use even more RAM when this branch is merged https://github.com/sverx/devkitSMS/tree/PSGlib_test as it adds separate attenuation for each music channel, so that's 3 bytes more than what was previously used...
Anyway if I might suggest - I suspect you could save one more byte by also removing the PSGSFXStatus variable and directly testing if PSGChannelSFX isn't zero to see when an SFX is playing.
so you'll not be happy to see that I'm going to use even more RAM when this branch is merged https://github.com/sverx/devkitSMS/tree/PSGlib_test as it adds separate attenuation for each music channel, so that's 3 bytes more than what was previously used...
Oh no... I don't need this feature, so I think I'll stick with the current version, for that project at least.
Anyway if I might suggest - I suspect you could save one more byte by also removing the PSGSFXStatus variable and directly testing if PSGChannelSFX isn't zero to see when an SFX is playing.
Oh good idea!
sorry for 'breaking' this - I have another change to push but then I'll work on a NO_ATTENUATION version that will make it possible to compile the library without the attenuation parts, and after that we might try this 'more compact storage' route. Hang on! :smiley:
@raphnet one question though: are you using attenuation or not at all? Because then using a NO_ATTENUATION variant with your more compact storage of flags would help you save on RAM, otherwise you'd better stick with your own fork thus keeping the attenuation as a single value for all the channels... :thinking:
@sverx I use attenuation (global, not separate) to fade out when switching songs.
For the project where I am low on memory, I have already copied the files of my fork to a subdirectory of the project, and this works fine for me. I mean, I'm not waiting for you to merge this or waiting for the new features you are working on, so no pressure. I don't think I'll ever update the forked code in my project unless there is a problem which I can't easily backport.
What would be best is a way to compile a SINGLE_ATTENUATION version of the library, which would also take the approach of using a bit field instead of one byte per boolean, for a minimum memory footprint. But as stated above, I do not need this now, and for other projects I usually don't mind a few extra bytes of memory use... So I totally understand if you do not wish to take this route. The library can already be compiled in so many ways with so many options, adding more options only complicates maintenance.
The library can already be compiled in so many ways with so many options, adding more options only complicates maintenance.
This is true, and your suggestion is wise. Since you're using a forked version with reduced memory footprint in your current memory hungry project, I will consider if I really need to proceed with my plan... I might do it anyway, but we'll see.
Thank you so much! :wave: