|
Post by spenoza on Jan 21, 2020 21:40:44 GMT
As to #1, was reserving the space for all possible saves the standard practice of the day? It certainly would eliminate some overhead from the rudimentary file system. As to #4, I think it's good to verify the accuracy of your save when you make it even if your save routines are very reliable, because that gives you a chance to try again to get a good save since you're still in the game and haven't yet lost your data. It adds extra complexity to the code to prevent against a hopefully VERY rare possibility, but I think it could be worth the work. I wouldn't say it's essential, but it strikes me as a very good idea.
|
|
|
Post by DarkKobold on Jan 21, 2020 21:51:57 GMT
As to #1, was reserving the space for all possible saves the standard practice of the day? It certainly would eliminate some overhead from the rudimentary file system. As to #4, I think it's good to verify the accuracy of your save when you make it even if your save routines are very reliable, because that gives you a chance to try again to get a good save since you're still in the game and haven't yet lost your data. It adds extra complexity to the code to prevent against a hopefully VERY rare possibility, but I think it could be worth the work. I wouldn't say it's essential, but it strikes me as a very good idea. I don't know how most PCE games do it. I do know I got 3 save spots working in HuC, which feels like an accomplishment in and of itself, given the issues outlined in my first post. And yeah, I'm not sure that I love the idea of writing a "did the system save your data properly" routine. I'd have to write the data, read it back out into different memory, and then check it. I guess its not a huge ordeal... just... Ugh.
|
|
|
Post by spenoza on Jan 21, 2020 22:12:39 GMT
At least the data is small.
|
|
|
Post by turboxray on Jan 21, 2020 22:29:45 GMT
Maybe because BRAM is accessed in slow-mode (cpu set in 1.79mhz), a single block transfer was considered more favorable in terms of speed? Seems like a silly thing, but it's still a thing (some games have music that gets stalled and 'notes' get drawn out for like a couple of seconds).
|
|
|
Post by dshadoff on Jan 22, 2020 1:35:27 GMT
Many of elmer's statements are based on following-generation machine issues, but should be considered when working on the PC-E.
One major point: -> In order to ensure that BRAM is not corrupted - for the game in use and especially for other games - write accesses should be as atomic as possible. This means to prefer 1 larger write rather than 25 individual writes, as something could go wrong in the middle. IN PARTICULAR, this is especially bad for BRAM systems which are filesystem-based, as the filesystem itself could become corrupt.
Another major point: -> If the game can possibly have up to 3 saves, there is an advantage to allocating them in one shot rather than separately: the additional available-space checking which would need to happen when allocating the second or third save point. It's bad enough that you would need to use precious space for error-checking in the middle of gameplay, but you would need to have more than one instance of the code (initial + incremental). Those instances can get out of sync with each other when facing bugs - and error-checking is where a lot of bugs creep in. Doing it all at once is cleaner for support.
|
|