After some hard time I started to get the general idea behind the DS and
it's 2D graphics and decided to make some small components for maps, sprites and text.
That seems to be missing or poorly implemented in most libs & homebrews.

What does this mean ?

I want 128 sprites on screen, not 128 different spites in video memory or 128 sprites per level.
I also want 1024 tiles on screen not just 1024 tiles in video memory or 1024 tiles per level.
Something that doesn't limit you, or at least very little.

So these mini-libs do just that, you can have about as many sprites as you want,
and pick tiles from about thirty two thousand ones (this can easily be augmented,
but 32768 tiles, thats already 2MB and you can switch tilesets if you want to too).

What it doesn't do:

It doesn't check the touchscreen pen position, doesn't do sound or other things.
An easy to use sound library along the same lines would be nice though but
not in the pipeline at the moment.

How does this work ?

VRAM managers does the trick, check the code if you want to know more^^
One thing about limitations though, as there are only 1024 possible references
for sprite VRAM locations, using a full 128kb Bank will force the manager to allocate
twice the memory normally used for sprites with the size of 8x8.
This is transparent so don't even worry about it if you don't want to.

What is not implemented ?

Most things are working, but only in 256 colors.
The sprites doesn't have access to the extra palettes.
The sprites has no rot/scale/flip abilities (work in progress)
The code has some really slow parts (the text for an example).
There are no destructors either so for the time being you have to
stick with one cSpriteMain and one cSpriteSub from start to end.

How do I use this ?

Sprites:

You decide how much VRAM should be used (you do the setup, check the examples)
You also must register all sprites you want to use in the game once in the beginning
of the game (BTW, sprites with several frames must be stores top-down, for examle: an animation
with 10 frames of a 32*32 sprite should be drawn on an image with the size of 32*320 and
then converted).
The registration returns an integer (starting with zero and +1 for each frame registered)
which is used by you to draw that particular frame on screen.
Then just draw sprites (maximum 128) every frame, that's about it.
One thing about the registering, you can register an allocated RAM space and
change that (make dynamic fire for exeample, or write text like the "text" part does),
just flag the ForceVRAMCopy when you have changed the ram data so the manager copies it to VRAM.

Maps:

Set the palette, give it a tileset pointer and a map pointer.
The map is actually converted Mappy .FMP files.
Set the position of the map each frame(if it has changed) and that's it.

I use Mappy to make maps, that's not the ultimate solution I know but it's free
so this is the format my converter takes.
Feel free to contact me if you have a better map maker :)

To draw sprites :
use the instance of the spriteclass (one for each screen if you need both) ex. cSpriteMain:
cSpriteMain->DrawImage(nr,x,y,z,depth,...).
and at WBlank, call
cSpriteMain->VBlank();

Text is a bit harder, actually not, but as it's not finished yet
you have to either wait or use the stuff as it is or try to fix
your solution yourselve.

You need to capture 2 64x64 sprites from the Sprite class (download the example code at the bottom of the page)
where you want to show text, then just use cText to draw and show stuff.
Really basic at the time being, but hey, it works.

I think I'll make a post on gbadev.org so any comments are welcome.
If I haven't done this yet and you want to contact me; send me a PM on the forum.

/Valmond

ps. I ripped the copyright/legals from the nds.h, tell me if this is not an acceptable paractice. Or if it is.

There are some *.exe files in the 'orig_data' folder, draw/slide/batch 256color images or .FMP mappy files

on them to create 'ludlib' compatible files (the DS_32bmp_to_16.exe works too and makes data for a 16bits BG).