Tuesday, October 18, 2016

sprck || fail.

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: Another curious thing, on the "animations" subset: one page makes reference to tiles that are not in the spriteset! possibly unused things that were inserted when the page was first created and then deleted before first saved into the spriteRAM. I guess I'll need to make sure I have some automated test that do something like that, too.

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"  ...


Sylvain Pypebros said...

# 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

Sylvain Pypebros said...

block #0 has been forbidden, but when it was on a 32x32 page, the blocks 1-3 were not returned to the free list.