Saturday, December 31, 2005

Tileset [t.a.g.]

Before I can show you how to load graphics with the GEDS engine, I must ensure you all know about how the NintendoDS builds the image we see on screen. I'm using the tiled mode here, where pictures are made of elementary 8x8 pixels elements called "tiles".

You have likely seen level editors where people drop little blocks to create their level rather than using larger "assets". The tiled mode pushes that one step further by structuring the video memory so that it natively works with little, 8x8 blocks. That is, one part of the memory will store such block and the other a 'map' telling which block to use at which place. Some can be used multiple times, some will not be used on this image. The technique is as old as the 8-bit era and was also used in almost every 16-bit machine.

What has changed over the generations is the number of individual colors that can be used in a tile (from 3 to 255) and the number of layers of such tiled maps that you can compose to get your final image (from 1 to 4).

A large part of the .spr files created by the Sprite Editor for DS is a dump of the "tileset" part of the video ram, so that you can easily load it and start rendering scenes with them.

Code:
 
  SpriteRam myRam(WIDGETS_CHARSET(512));
  SpriteSet mySet(&myRam, BG_PALETTE);

  mySet.Load("efs:/bg.spr");
 
There is not much the application program needs to do about it: the SpriteSet object of libgeds will exchange data between video memory and SD card storage (or here, filesystem embedded within the .nds ROM). All we need to do is tell it where to store the color map (the palette, the NDS has a specific slice of video memory for that purpose) and where to store the tiles (as we may want to keep some room for a text font and screen maps themselves). Starting at 'character 512' is an easy way to avoid conflicts with things set up by the engine, but you could very well create myRam(BG_GFX) and claim that all the (upper screen) video memory are belong to you.

No comments: