I would think a simple:
Code: Select all
cat datafile.bin >> gamefile.uze
I would think a simple:
Code: Select all
cat datafile.bin >> gamefile.uze
This is an okay answer for "right now", but first if we settled on standardization, the header fields governing it (where the data is to be located) should be agreed upon. Later possibly the Packrom tool could be extended to support adding data files into the .UZE along with generating the appropriate header.Artcfox wrote: ↑Sun Apr 15, 2018 9:55 pmI would think a simple:would suffice, though you may want to pad the beginning of your datafile.bin so any real data you want to read starts on a sector boundary.Code: Select all
cat datafile.bin >> gamefile.uze
An idea how you could protect your game against this problem regardless of how you store saves on the SD card:
Interesting idea. Most games that save state offer a choice of New Game or Load Game already right? I wonder if that would be enough to cover the special case you just mentioned without requiring extra checks. A new user starting a game would probably pick New Game, because they wouldn't think a saved game would be bundled with it. I guess only if a game didn't offer this choice would it be a problem, and then there would be no in-game way to start a new game.Jubatian wrote: ↑Tue Apr 17, 2018 12:49 pmAn idea how you could protect your game against this problem regardless of how you store saves on the SD card:
You can still use an EEPROM block for your game. In this EEPROM block, you could store whether the game was ever started on that particular Uzebox, and if you detect that it wasn't, while the game has some save state, you could offer a clean start (but it is important to make this an offer as the player could actually want to continue a game on a different Uzebox or emulator).
For one offering such, of course this isn't a great concern at all. Probably rather games like Alter Ego, which unlock levels as the player makes progress: there no such menu is offered, you get the selection of available levels based on your advancement.
Normally no. The point of the save area is that a library can be made for it, which makes write access a lot safer: the library ensures that only the designated area can be written in a UZE file. Of course even now nothing stops you from messing around with UZE files from within something running on the Uzebox (for the kicks, somebody could program a virus ).
On this, and also CunningFellow's wariness for rogue SD writing, I understand the philosophy here and agree with the intent. I would call some statements "very conservative" though, where in my opinion "moderate" is the right path. Seeing as no outright "liberal use of writing" view seems to have been expressed, I am willing to be the bad guy and play the Devil's Advocate here(with an opinion a bit more pointed than the way I actually feel...for science!) My example would be a successful use of SD writing. I built a new more difficult episode for Toorum's Quest using the editor, and saw no problems with my SD at any point. That editor feature is probably more impressive than the rest of the game in reality, and I tested it more so than other parts, because I was writing which is dangerous. To be fair, I should add "WARNING THIS PROGRAM WRITES TO THE SD CARD" whenever the user selects the editor. Bigger more creative things can be had in that direction too; sounds interesting!