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.

• see complete tutorial code on github
• see corresponding post (#2) in gbatemp tutorial thread.

mybrew (t.a.g.)

You've reached the last post in the "mybrew" thread.

These post present the software development and releases I've been through on the Nintendo DS. That captures everything about the sprite editor, the level editor and the animation editor that I intend to use for building Bilou's adventure, plus the Multi-purpose transfer-and-testing tool dubbed 'runme' and (of course), all the demo games that fill the gaps until the future Grand Release, such as Apple Rumble, apple assault and the other gedsdemo :P

It may miss some mere coding or documenting posts, and is wider than just the milestones. It doesn't cover the projects that haven't started yet such as Deep Ink Pit, although it has received a codename and a gameplay target.

Although all this software is homebrew (and open-source, btw), the 'homebrew' tag is for other's software on discussed on this blog.

Somehow, it would be a shame to keep that for myself. If I'm right, it would be as good as having a game maker for NDS on the NDS. I started a tutorial series on github to share the knowledge of how to use my homebrew engine. The first layer is a framework of compilation scripts (Makefile) together with low-level libraries (including a modified version of 0xtob music player. Well, everything needed to get a first program built and running.