That was needed, good job writing that up.
Artcfox wrote: ↑Sat Apr 14, 2018 12:58 pm
For a 32x32 animated icon, I think we could have special magic bytes written to the 16x16 icon field and a pointer to the 32x32 animation, and length.
I would very amused if we could actually utilize this, as I generated quite a few icons for Emuze for different games which could double over. That I recall, Alec said the original bootloader was packed to almost the last byte which Sandor also stated about the new bootloader. I am definitely in no place to make suggestions about implementation for either of those, but if it were somehow possible to do it would be a very cool feature even at 16x16 I feel.
Artcfox wrote: ↑Sat Apr 14, 2018 12:58 pm
My preference would be for the. uze files to remain read-only, just because I copy them around all the time, and having game state come with them might be bad.
This might make the most sense and probably most SD games wont write anyway. I am only aware of Toorum's Quest editor which writes on it's own data file, and that could just as well stay a separate file(having completed the editor and releasing 1 very hard episode, I became bored to develop more of them). In a certain way I guess the author of each particular game knows best, but in general I agree. It does seem a bit "impure", but excessive files on the SD card is also annoying. In TQ for instance, there is not really game state since you start from the start each time, and the only thing you are hauling around is new episodes.
I mentioned this a while ago, but I am really convinced something like
this can work well. Toorum's Quest does use that, and now that I remember that, I was going to make AE do it too so I will for all things I do further anyway. I would be interested to discuss anything involving that so that it can be modified to fit everyone's purposes. The main motivation is to eliminate excess files on the SD card. There were possible arguments against it, but mainly it shares the same "risks" as writing to the SD in general, that a runaway bug can screw everything. Ultimately I never saw that as a compelling reason not to write, versus the interesting directions writing opens up, since no real life critical information should ever be put on Uzebox. Something like Pacman long ago had a bug, which would break the whole EEPROM. A couple users got broken saves on accident, not a big deal, it was fixed. Probably a lot of games directly copied the fixed code for interfacing with EEPROM ever since. Anyway...I will stop my ideological push here since I think most agree writing is an interesting new thing.
Jubatian wrote: ↑Sat Apr 14, 2018 8:49 am
Now that it exists, it could be nice to add some extras for supporting extra data. I think about two important elements which could be nice to have:
Sectors reserved for Save states for games which wish to use the SD card to store saves without needing anything complex
Sectors reserved for additional game data, would be particularly useful for SPI RAM games
If totally pragmatic about it, save sectors could have some benefits versus the concept of not keeping state in the game which I also understand. I guess I am not sure which "side" I am on right now, since I can see pros and cons for either.
Sectors for additional game data--what exactly do you have in mind for this?