Laceys Investimigations

I’ve just come across a great homebrew app by the name of Animanatee - for making up animations on your DS! Includes some basic onion skinning and two layers to use. This is my first animation done with it, though I only used one layer: Skate Dude

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

Been quiet for a while, not that anyone ever reads any of this I suspect. The point of it is really just to jot down some notes that might come in handy when somebody googles homebrew DS stuff. Meh.

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.

Not that much fun but thought I’d stick it up anyway - I’m in the process of replacing the lovely Zelda artwork with my own crappy tiles.

The little dude is mine though!

Finally able to log in - would appear I forgot my password a bit!

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 :)

Simply broke. I went to insert the micro SD card as normal and it just wouldn’t stay in. Catch wasn’t clicking and the spring was just pushing the card back at me - quick search on the net shows this isn’t rare either, which is a shame because apart from that the card is great.

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!

Not quite - I was testing my VRAM stuff, wanted to load a map and some tiles - rather than drawing some I figured I’d just use a scene from one of my fave games: A Link To the Past. Because I haven’t bothered to write the function to load the palette yet it’s being drawn with my debug palette, and the result is a glorious image which looks like it’s straight from the good old Spectrum. Thought I’d share it!

Having played around a bit, and with the advice of others I decided to drop efslib, and am now using the NitroFS system created by Eris

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.

Just thought I’d share my choice for file system for the time being, rather than using something like libfat directly I wanted a solution more similar to the official way of doing things, partly because it means I can have all my files in one place without having my data compiled statically in the application.

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.

While writing a quick and dirty function to get some debug tiles on the screen, I forgot (it’s been over a year since I last did any DS code) that you can’t write to VRAM 8 bits at a time. I think this might be true for all RAM, though in other cases it’s likely the hardware does a 32 bit read then write. Either way, if you want to write some debug tiles to the screen make sure you write either 32 or 16 bits at a time.

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!

Last time I looked at home brew it was nothing to shout about, however that was a long time ago and the libraries knocking about now are nothing short of awesome.

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.