To achieve this I force memory to a 16-bytes alignment, to
achieve this code will allocate 15 extra bytes on the heap
but each Block and Frame object will be 8 bytes smaller. Given
they are created on the fly and passed around a lot, I think
this is a good tradeoff. Not super urgent, but I got it done
now, mostly to make sure index is used in a sane way and doesn't
take too large values, which would prevent me from making this
change later in the future.
MemoryCard returns Block objects that are constructed on the
fly, any_iterator needs to have a parameter that makes it
use my non-ref type as its internal reference return type.
This is still missing the pointer version of this change.
Currently broken, it won't compile.
This change's been unstaged since 2020 I think, it was
probably just to test the idea of having a bottom grid
acting as the general "database". It's working though it
needs changing, I'm committing it and will modify it
as needed in the future
Note that this requires meson 0.63+ because: "before
version 0.63.0 Meson would fail to find Qt 6.1 or later".
Update is to fix a KDE error I was getting when opening
the file selector dialog:
> kf.service.services: KServiceTypeTrader: serviceType
> "ThumbCreator" not found
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.
