Ok, this time, let's try to get that .spr file fixed. That's the right timing to get some framework that read and write .spr files on my host platform with the engine's C++ code.

You may remember this spritesheet captured some times ago, where 'striped'  tiles were suspected to be declared free although containing pixels ... It's a bit more complicated apparently: the tool building those spritesheets wasn't processing 32x16 blocks properly. The real "trouble map" looks more like below: everything seems correctly aligned between the two versions. Well, everything except the last tile which is mapped on two different pages ...
It would be tempting to believe that with that double-mapped tile fixed, everything would work fine. For small blocks (16x16 pixels), the "blue-ish" free blocks would be used first, then the "red-ish" blobs (16x32 or 32x16 pixels) would be split by try_harder_alloc(). Except that splitting isn't allowed in normal allocations. In fact, if I can rely on cscope's output, splitting is *never* allowed.
Adding some more 16x16 sprites thus grows the file closer to its limit.

...