Good news: I managed to reproduce in a controlled environment the corruption of a spriteset. Bad news: because I had no idea what was the possible cause of such corruption, I just went through a random set of deletions and then a random set of recycling of the released blocks. And repeating the process from a sane initial spriteset until the "checker" tool reports something abnormal
One interesting thing, though: what's abnormal is abnormal twice: not only I shouldn't have "cross clusters" in my sprite pages (two slots on two pages actually referring to the same tiles), but I possibly shouldn't have "0" at all (it is reserved on most spriterams) and I definitely shouldn't have some odd tile number since the smallest allocation unit so far is 4 tiles.
edit++: I think I got most issues fixed now. I'll have to give it a run on a real device and see whether I accidently broke something with all the "refactoring" ...
- + 
Vote for your favourite post
5 comments:
# step one: generate a 'checkme' by killing some things and then try to add some blocks to it.
while perl SpriteEditor/test/tester.pl cleaned.spr c0 k3 n0 acc && cp /tmp/checkme.spr kills.spr && perl SpriteEditor/test/tester.pl kills.spr c2 k0 n2 acc ; do echo "AGAIN" ; done
block #0 has been forbidden, but when it was on a 32x32 page, the blocks 1-3 were not returned to the free list.
[%x:%{tbBh6?!@}] is produced during SpriteRam::unpack().
- hex value is the location
- letter indicates the kind of mark (is it one free tile, a 2x2 free block, ...)
[%x->%lx %lx] is produced by SpriteRam::mark()
- first is a tile location
- next two are generated bitmask
When a page is wrongly referring to a tile that has no valid content (e.g. is on the free list), sprck cannot automatically decide to clean it. It has to be done manually with -s pageno blockno_in_page tileno_in_ram (usually with 0xffff as tileno_in_ram to mark it unused).
Post a Comment