Maybe some blocks should be marked "free" and they aren't, maybe I really need to optimize so that I lower the allocation watermark ... or maybe it's something else.
At first, I thought some visualization of the spriteset content (preferably on SEDS's file window) would *definitely* help to figure out. Something like a 32x32 sprite can providing one-pixel-per-spritepage. But that'd be a bad idea.
I mean, *I* would find it handy, but it shouldn't be the problem of the sprite artist to organise the tileset so that sprites fit in. Doing something like "move this page to 'draft', click 'optimize' and then move the page back to 'sprite'" is a hack, not something I want to read (and definitely not write) in any user manual for my software.
The root of the problem is in the tiles allocation: it prefers allocating what has been recently freed, while it should prefer what has low values and would lead to a compact enough tileset. Think about it.
Wednesday, June 13, 2012
Repaired, and still not working
Tags: allocation, choice, coding, data recovery, english, sprite editor, todo
Subscribe to:
Post Comments (Atom)
2 comments:
spriteram.compact() already does everything is needed to ensure most efficient tiles allocation. Maybe we just need to compact() automatically from time to time ...
and definitely, we need to invoke it if we've been shifting a sheet from one spriteram to another!
Post a Comment