However If i were to maintain them, I would use this message board, and just create a new section called ‘save ID’. Each topic would be ‘request for ID 1’ and then whoever is in charge either approves or denies it. People who want an ID just pick the next number available and submit a request, and there could be a sticky up the top for any out of sequence numbers available for requesting.
I don’t think we even need a centrally manged list of game IDs now that we have game manager/installer apps. Just let each of those mange there own list of IDs. All the games need to do is reserve a bit of extra space at the start for the manager to store a game ID.
When the manager installs a game, it needs to save the old image including the ID, possibly with an option to disable that. It should then check to see if it has a saved eeprom for the game being installed, and if so install that. If not, it needs to get a new ID and set it in the eeprom. This may require running a small app before the main one, but it’s certainly possible.
Working properly with multiple apps/platforms requires that they agree on a format for the saved eeprom image/ID pairs and cloud storage, but getting that seems easier than getting all game developers on board for an ID list.
It won’t work for games in development, but that doesn’t seem like a problem.
I don’t know if eeprom backup is a feature of any of the game loaders, but it should be. The only thing out of all of the above ideas, that really should be suggested is that the game uniquely identifies itself, either by some sort of code, or just a plain filename, so that any backup method would know what to name the save file, and that to load.
There’s a few best practices though.
Mainly don’t stick your data right at the start of EEPROM because too many games do that already and it wears the lower block out quicker.
Also make it configurable by changing a value in the source code so people can move it if they want.
I’d recommend using a const (and ideally constexpr) variable for that, but most people just use #defines (much to my sorrow).
I think it’s too late in the game to create a standard API that sketches would use, especially considering the number of sketches out there that do their own thing and would have to be modified.
I was thinking of creating a wiki in this forum that anyone could add to or modify, to list the EEPROM area that each sketch uses. The format would be kept simple, containing:
The name of the game. If different versions of the same game were released that used different areas (start or size), a separate listing would be made for each version.
A URL for the location of the source code, if available.
The start and end addresses of the EEPROM space used, the same as what would be provided in the info.json file of a .arduboy file. The entries would be kept sorted in order of start address, and secondly size (largest areas first) for ones that start at the same address. Sorting this way would make it easier to find if an area had been used, and help to locate an unused or little used area.
If possible, notes on how to modify the source code to change the area used.
I haven’t created the wiki yet because I wanted to provide a few entries, to get things started and as examples of the format. However, I haven’t found the time to research the information to create these entries.
If anyone wishes to get the ball rolling by providing the information for their game or someone else’s, as a reply in this topic, I’ll create the wiki once the info for a few entries is available.
If this idea proves to be useful, there’s the possibility that the wiki could be moved to somewhere on the main Arduboy web site, where it would be easier to find.
@MLXXXp The wiki part would be helpful, as of the last hour I’ve been playing with the idea of trying to go through and list the EEPROM addresses the popular programs use, although that would be a LOT of work for one person especially if it was a personal project as opposed to a public wiki where developers could openly add the info.
I’ll try to refine what data I already have and post it as I didn’t note some aspects that would need to be displayed, hopefully that will get the ball rolling like you say.
If people have been putting the correct addresses in the info.json in their .arduboy files then it should be possible to make a web crawler to walk through all the games on http://arduboy.ried.cl/ and scan the info in (it would need to be able to unzip the .arduboy files and parse the json).
That would serve as a good initial pass.
It might also be possible to programmatically scan the source code of sketeches to look for EEPROM writes and try to extract the addresses that way, though it would only manage a handful without more complicated logic. At minimum it would need to be able to identify variable/define names used in the EEPROM writes to figure out the base address.
Hrm, I misremembered that.
That makes things a lot harder.
If you have the means of being able to identify a program that’s loaded to the emulator then you might be able to make all the instances “phone home” and store what they send back in a database, that way you could leverage the power of people playing games to log EEPROM writes on a larger scale (like recaptcha does for books).
If you further limited it to unmodified .hexes acquired from @eried’s repo then you could eliminate some of the ‘noise’ and just focus on the ‘published’ games.
That’s unfortunate. I wonder if @eried’s server could?
If not, maybe something could be arranged with @bateske - rent a database server for a month and start a community-wide “help us figure out the EEPROM addresses” thing.
(Admittedly you could gather a bunch of people and ask them to sit and read the source code of all the games, but telling people “all you have to do is play video games in a browser” is probably a better motivator.)