Library updates

[agentavacado]

I've been making a game recently, and I'm starting to realize thats it's going to be a little too big for the 2 kb of RAM and 30kb of flash the Gamebuino has. I've been thinking of a way to solve this and I think I found it. Make several "games". Once the Gamebuino is done with the section of the game the user will be prompted to save and load another "game"(the next part, containing the content it needs to continue). So a gb.changeGame(String) function to speed up this process. Although there is a flaw, how will the EEPROM data or RAM get to the other game? As far as I know there is no way to share a .SAV file or prevent cleaning the RAM when the game is changing. What I'm asking for is a way to share or read(/write) another game's .SAV file, or create an array that will not be cleaned when a new game is loading(kinda like the settings).

P.S. I'm not sure hooking up another gamebuino to store the data while the main gamebuino is loading the next part would be a good idea.

[Sorunome]

there is already load_game("MYGAME") with which you can load another game!

[agentavacado]

there is already load_game("MYGAME") with which you can load another game!

Hmmmm... I didn't see it on the reference page, I must have looked over it while looking through the contents of the library. I there a way to pass information to the other game? EEPROM.write stores it to a .SAV file that cannot be accessed by any other game.

[Sutchig]

I didnt look at the library, but maybe you could write your own "MYGAME".sav file to sd with the information you need before load_game. (this way you have a savegame btw Downside: you have to include a fs-library. The .sav-file is a 1:1 copy of the eeprom.

[Sorunome]

If you load a game via load_game() (yeah it isn't documented on the reference page as it technically isn't part of the library, you can see that as it doesn't start with gb.) then the EEPROM won't be changed at all, so you could use that to pass on data.

[agentavacado]

Sounds great so far, I'm just wondering... are there limited write cycles for the EEPROM? I might be thinking it wrong and it writes to the cpu eeprom then erases it when loader is loaded and saves it to a .SAV file. I'm afraid it might blow the eeprom, since this strategy might really eat on those cycles.

[Risike]

I've read yesterday than we can write 10 000 times on the Flash and EEPROM but that was an information without sources on an arduino forum.

[Sorunome]

Yes there are limitations on writing to flash and EEPROM, if I recall correctly they should be so that for normal use you can use it for years.