I would embed that video but can’t make it work. At least not in under 60 seconds.

In other, more imortant news, Eris has updated her NitroFS stuff, so if you’re using it I’d suggest grabbing the latest version for a couple of minor fixes and improvements.

The little dude is mine though!

Anyway, tech is coming along nicely, got sprites on the screen now too, will get a screen shot up shortly. Coming next is support for maps > 64×64 tiles.

Hit a bit of a ‘gotcha’ whilst using my own structs to represent data layout in OAM, apparently having a union start after a 9-bit variable results in padding being inserted before the union - meant my values were being written 7 bits further on in memory than they should have been. Of course, if you just use the structs provided in libnds you won’t encounter such an issue :)

For those of you who have endured this pain and don’t want to use tape to hold the card in, I’ll share what I discovered. While poking around trying to get the catch to work, I pushed the card in backwards… and it clicked. Eagerly I pushed again to release the catch and try it normally but alas it still didn’t work - what I did find after more fiddling though was that by pushing it in backwards so it clicks, you can then pull the card out and put it in normally. It won’t click into place, but the spring won’t push it and fair bit of shaking the console upside down hasn’t dislodged it either - so if you don’t want to send it back and get a new one this may be the solution you need!

It’s a similar set up, i.e. lets you keep everything in a single file w/o statically linking in your data, but it’s got a nicer interface (you can just use fopen/fread etc.) and I’ve got it working nicely on both my DS and on No$GBA.

Hopefully now I can finally get some real graphics on screen - I’ve written half a VRAM manager for dealing with tile sets and maps, just need to give it some more testing now I can load in proper data.

The advantage of not having the data static is that you don’t waste valuable RAM storing it all permanently, and the advantages of having it all in one are pretty obvious with regards to distribution.

So for now I’m using efs lib which is built on top of libfat, and even comes with a switch (#define) so you can turn it into simply a light weight wrapper for libfat should you have trouble using it on certain devices or with certain emulators.

I’ve built a further wrapper around this myself so in my code file references are purely integers, though whether I’ll keep this I’ve not decided - it’s extra overhead for not much benefit, but then I don’t forsee a need for super fast file access either just yet.

The following code simply ‘makes’ two tiles in VRAM, i.e. two blocks of 64 (8×8) pixels, filling the first with 0 (for the first palette entry) and the second with 1 (for the second palette entry).

u16 *pTiles = (u16 *) BG_TILE_RAM(1);

for (i = 0; i < 64; i++)

{

	if (i > 31)
		pTiles[i] = (1 << 8) | 1;
	else
		pTiles[i] = (0);
}

Obviously this isn’t the most flexible or attractive code around, but it illustrates the point!

I’ve been coding for a few hours tonight and already seem to be making good progres… though I’m not sure what on just yet. Probably some kind of top down rally thing just to get my tech together.
I’ll shut up for now.