Personally I’ve found that eeprom_update_block and the rest of the avr-libc family uses less memory than the EEPROM library, even if it’s slightly less convenient.
It’s correct, but probably not the best way of saving.
You probably won’t burn the flash out because you’re using update (which doesn’t write to eeprom, but still reads from eeprom),
but it’s better to either have a manual trigger (e.g. an option on a pause menu) or have an event-based trigger for saving (e.g. touching a checkpoint).
You can use the millis function to get the number of milliseconds elapsed and you can use that to do more accurate timing, so you could save every minute or something.
Or if your game has a day and night cycle (presumably you’re making a survival game) you could save at the end of each day/night, or each quarter of a day (morning, noon, evening, night).
In this case, it’s a virtualpet-like game; it’s costantly running and i want to give the user the option to “reset” the game, just in case.
The reason why I want to periodically save in EEPROM it’s to give a person the ability to turn on and off the game and find its virtual pet in a similar state from which the pet was the last time the game was turned off or the battery died.
Does it make sense? How resource-intensive is saving to the EEPROM?
At the moment the game is designed to decrease the stats by ~ 0.001 or similars every single frame, again, i’m not sure if this is a good idea.
@Pharap Thank you so much for all the info. I’ll implement my solution in the next few days and report back!
It’s probably best to do a ‘quicksave’ feature, where the player can choose an option to save before they switch off rather than just switching off.
Saving takes about a fraction of a frame, so getting the player to pick an option from a menu won’t be that much slower than allowing the player to just turn the Arduboy off at any point.
The only real advantages would be to prevent the player escaping a bad decision/event (i.e. they could reset their game to before something bad happened) and/or to prevent progress being lost if the battery suddenly runs out.
A few notes about virtual pet games:
Once you turn the Arduboy off, time is effectively ‘frozen’ from the pet’s perspective.
The Arduboy doesn’t have a real time clock, so there’s no way of figuring out how much time has passed, so you can’t even simulate the lost time after turning the Arduboy back on.
Some other people have experimented with the Arduboy’s ‘watchdog timer’ to try to put the Arduboy into a low power state that periodically wakes up to keep everything running.
You might be better off using large integers rather than floats because the Arduboy doesn’t have an FPU (floating point unit), but I’ve never actually run any tests to compare the processing speed/progmem size for each approach.
Another alternative is to accumulate frames with one variable and increment a stat when that variable passes a certain number of frames.
Or if you want to be framerate independant, use millis to accumulate time and make changes based on actual time passing rather than frames.