Local Storage

[lenardg]

trafficstars

Regarding storage of save games and scores, it would be great to have an API for that, so that we do not have to worry about file acccess or block writing. I think you had quite some discussions earlier on how this whole thing should work, what should be in the device memory vs the SD card. I don't remember is there was a definite solution reached?

Anyway, for local storage I would like to see something like:

• ls_enumerate() -- Enumerate saved "blobs".
• ls_save() -- Save a new blob with a given name. Give it a name (string), data (pointer to data), and a length. It stores it some where.
• ls_get_length() -- Get length of blob maybe? Give it a name (string), return the length
• ls_load() -- Load a blob with a given name. Give it a name (string), data storage (pointer to storage in memory) and a length of the buffer. If it fits there, it gets loaded.

(ls stands for local storage, and of course this just brings up another issue on how you want to name these things in code ... prefixes vs namespace vs classes, etc? )

More questions that need answers / discussion:

• Should apps have limits on how much data they can store?
• How to worry about storage running out?
• Does Local Storage require an SD card?
• Should we be able to set a priority for storage (so for example the scores need to be saved always, but save data or auto save data might or might not fit).

[Gadgetoid]

Having gained the revelation recently that our Flash is 32MB not 32Mb then I'm really coming around to the idea of actually initialising part of the Flash with a FAT32 filesystem so that users can save games and- of course- Lua scripts without requiring an SD card.

I like the localstorage paradigm, although my main concen is how do we disambiguate blobs/assets between games? A simple/sensible approach might be for each game to exist within a subfolder as standard, and for all its assets to live alongside it. Using subfolders might make metadata handling easier since a game screenshot can almost be a regular on-disk image (the STM32 can, in theory, handle jpeg) and the title/description just saved in a plain text file.

Having the system save other state, or load assets aside, I wonder if the ability to save a game should be handled by a standard system menu API, rather than individual endpoints?

IE: At init up you might blit::register_savegame_data(pointer_to_savegame_struct, length_of_savegame_struct) and then when the user hits the "Menu" button they can "save" via a standard interface (like you see on the Playstation 3/4, Vita for example) into either the SD or Flash depending on what they choose.

This would mean you only need to keep a struct with all your game state, and the rest of the save/load functionality is available as part of the engine/HAL.

This is all a bit of a braindump at the moment, but to answer your questions:

1. I think limits on storage are probably unecessary, at least on the SD card side of things
2. I think most systems don't worry and fail poorly in cases where storage is low, I guess we can do a "free space" check and only write a file if it will physically fit. I would be surprised if it were a huge problem.
3. I'm reasonably sure we'd like 32Blit to "just work" without an SD card, see comment about a Fat32 FS on the Flash above
4. I think worrying about storage capacity is definitely a "we'll cross that bridge later" problem- we know broadly that it's probably impossible for a savegame to be >1MB - excepting some really crazy swapping-state-to-disk - since the chip just doesn't have much RAM.

[Gadgetoid]

We now have a pretty comprehensive file API, so users can leverage that to facilitate savegames to SD card for the time being- but I do strongly believe that saving/loading games should be an API feature with a standard UX.