Monday, May 28, 2012

sponge-hands-and-ink-and-mockup

Here I stand, guilty of doing low-level debugging where the situation wasn't calling it. Now that I have a "test level" for the school zone, it's very tempting to start writing more monster code. I thought I could easily hack a Sponge Bop test while *deline was asleep this afternoon, but for some reason, only the first frame of the animation did show up. The rest was just rubbish: Bilou feets and similar stuff.

Was my data corrupt ? Was there some nasty bug related to 32x32 sprites in the revised game engine (there shouldn't have been?) I scanned virtually everything, but the data I was (painfully) reading in DDD made little sense.

I finally decided to hack some debugging output in my .spr to .png converter to see what "pages" were containing, and I turned suspicious over the following entry:

4x4=1020,1036,1052,1068,1116,1132,1148,1164,1180,1196

1036 ? 1052 ? that's a bit surprising for a sprite number ... when I looked at the shape of the spritesheet, the obvious (finally) hit me: the DS can only enumerate 1024 tiles for sprites. No more, no less. Everything on the fifth column of the spritesheet can be nicely viewed in the SpriteEditor, but cannot be used in games. It's not even the first time I encounter the problem >_<. I think I'll need something in the Sprite Editor that warns the user about this when saving a tileset. And I'll have to figure out how I solved the problem last time...

Oh, and it's been over one year that I'm longing for a "draft" tileset and a "animation" tileset in .spr files ... I think it's now time to add this to Sprite Editor ...

developments:

  • [done] enable up to 4 SpriteRam;
  • [wish] show how much tiles are used in each SpriteRam (other than pressing L+START to enable debugging, I mean), and which spritepage should be moved to compress the tileset.
  • [done] shrink spritea.spr so that it can be fully used by the engine;
  • [next] enable 16x16 <-> 32x32 sheet conversion;
  • [next] find a way to use the ink animation in the level;
  • [done] produce a warning when saving a file where sprites or blocks set has too much tiles;
  • [done] allow hint on which tile is used when producing tilesets with spr2png.pl

regression tests after the edit:
  • [ok] change the spriteram used for a page
  • [ok] save and load file with more than 2 spriterams
  • [---] use the "scan colors" and "color remap function" (actually, nevermind: it operates on the working sheet, not on the SpriteRam itself).
  • [ok] use the "compact tileset" feature (doesn't it just reduce the 'watermark' when last tiles are no longer used ? couldn't that be automated with load/save ?)
  • [fair] use the "color zap" (dirty bit and warning message "file your sheet first" ?)
  • [fixed] copying page only works for "blocks" pages.
  • [fixed] cursor-assisted deletion of objects doesn't behave as expected with 32x32 sheets.
I'm a bit surprised to see the "SpriteRam*" pointer so scattered all over the code... I might have to change them into "spriteram_no" here and there so that only some core component deal with sprdata[i] directly.

2 comments:

PypeBros said...

would it make sense that SpriteEditor comes with

class EditSpriteSet extends SpriteSet {

scan_for_color(uint sramno, uint colno);

etc ...

}


which would mean no global SpriteRam* sprdata[] remains needed ...

PypeBros said...

color zap is surprisingly slow and doesn't check the current work sheet :(