A PlayStation savegame manager.
King_DuckZ
5688775e6c
This forced me to think about treating block 0 specially. The problem was with block.index() returning [1-15], while the valid range for MemoryCard::operator[] is [0-14]. This discrepancy was very confusing. A simple solution would've been to just rename Block::index() to eg Block::id(), and then know that one has to do -1 on the id to obtain the index. I tried but discarded this option. I don't think it's intuitive either (what's id? is it guaranteed to be index+1? is it a random number, rather? I know I will forget in 6 months). Treating block 0 normally would, on the other hand, break range iteration, as the first iteration would always be on the TOC block, and all for loops would become 1-based. Also implementing size() correctly becomes tricky (size could never be 0?) I don't like the current implementation either but I did it anyways for now, so operator[] works as before, you can get block 0 by calling toc_block(), and Block::index() returns some silly value for block 0. This should work in the future too when there will be the possibility to forge a new block from scratch. You don't really want to forge a block 0 as that's calculated from adding the normal savegame blocks, and for the latter MemoryCard can just do the +1 internally when receiving a new Block. Besides Block::link_order() seems to like indices this way, with 0 being the first savegame and not the TOC. So it seems to be special in the original PSX API, then let's treat it specially. |
||
|---|---|---|
| data | ||
| docs | ||
| src | ||
| subprojects | ||
| .gitignore | ||
| .gitmodules | ||
| COPYING | ||
| epsxe000_xa2.mcr | ||
| meson.build | ||
| meson_options.txt | ||
| michele_epsxe000.mcr | ||