SMS_saveROMBank() implementation in SMSLib.h makes it only usable in the same scope as SMS_restoreBank() about devkitsms HOT 9 CLOSED

No, I'm not going to remove the existing save and restore features, just adding some new ones.

from devkitsms.

Let me know if SMS_getROMBank() works well enough for you 😄

from devkitsms.

Interesting!
I have a few possible workarounds but I believe the easiest is to just move the SMS_saveROMBank(); before your if, which means you'll save the current ROM bank even when you won't need it, but not a big deal anyway...

from devkitsms.

Yes, for my case I just put them together, but it's a bug that may not be not so obvious to the newbie :-)

from devkitsms.

Well, not really a bug in my opinion but surely it's an issue some other might stumble upon.
Maybe the solution is just to use a global variable instead of a local one? Also, what do you think about this @raphnet ? 🤔

from devkitsms.

A global variable would break everything for me. In my projects, I occasionally have more than one nested use of save/restore (inside functions called from other functions...) and also use this in a line interrupt handler for music playback.

Additionally, at the moment a call to SMS_restoreROMBank in the wrong scope should fail (in most cases) with a compilation error. If a global variable were used instead, then it would compile fine, but should the user ever nest uses like I do, there will be fun surprises at run time which I'm pretty sure will be extremely confusing for a newbie, as it will be more subtle than an outright compilation error.

Perhaps the documentation just need to be improved? For instance, stating that the saving must be done somewhere that is not out of scope for the restoring later?

Also perhaps pointing out the fact that after using SMS_saveROMBank(), there is absolutely no requirement to actually switch bank, and that using SMS_restoreROMBank() can be even omitted if you know the bank was unchanged. Given this I think one could rewrite the code from the issue description like so:

SMS_saveROMBank();

if(flashCartridge) {
    SMS_mapBANK(SAVE_BANK);
} else {
    SMS_enableSRAM();
}

//Do saving stuff

if(!flashCartridge) {
    SMS_disableSRAM();
}

SMS_restoreROMBank();

from devkitsms.

OK so maybe I could add a function that returns the currently mapped ROM bank value (a byte).

This way, one will be able to declare his own variable with the desired scope (either global or local to a function) and save the currently mapped ROM bank there.

Basically something like this would probably just work:
#define SMS_getROMBank() (ROM_bank_to_be_mapped_on_slot2)

I'm not sure about the name though. It needs to be clear that you're reading back the number of the currently mapped ROM bank... 🤔

Suggestions?

from devkitsms.

I can't think of anything better for the name. At least SMS_getROMBank() is shorter than ROM_bank_to_be_mapped_on_slot2...

I hope the next step is not removing SMS_saveROMBank(); and SMS_restoreROMBank() to only keep SMS_getROMBank()... That would be a bit disappointing.

from devkitsms.

I think the SMS_getROMBank() name it's fine! And as you mentioned, no need for deleting the old ones. But I'll mention in the documentation that it can only be used in the same scope :-)

from devkitsms.