devkitPro

Am reading a few tutorials, but none of them seem to explain exactly what all the BGs and Modes and stuff do. They say like "Text", "Extended" etc, but none elaborate enough on that really.

Specifically, I'm looking to program a tilebased strategy game, and whilst I could easily handle most of the game logic (yay 3-4 years of C & C++ experience, with x86 assembly somewhere in there...), I have no idea where to begin with the graphics. The most relateable game I can think of in terms of interface is Advanced Wars; a scrollable tile map consisting of pretty much the same 20 odd tile textures, and ontop of each is a tile/sprite of the units occupying the space.

What approximately should I do here? The sprites would need transparency, which GRIT does nice and easily, but how would I apply this? What mode should I be looking to use?

Also, one thing I find really helpful is a documentation of everything in the API. Is there any to recommend?

That aside, this is one of the best homebrew compilers I've seen. I seem to be able to throw everything at it and it can either compile the most abstract stuff, or perfectly errors at the problemic code o_q

Welcome to DS Homebrew, I hope you end up enjoying it as much as I do.

Here's basically what should become your bible: http://nocash.emubase.de/gbatek.htm

Everything you want to know, at a very technical level, is covered there. If I were to try to answer the question in just a basic way, there are 3 primary background types, Text, Rotation (Affine), and Extended Rotation.

At the most basic type is Text and will likely be all you will need for that type of game. If you haven't seen it already, dovoto's tutorial covers the idea around simple tiled backgrounds very well. http://dev-scene.com/NDS/Tutorials

This will be a spot the examples lack in a bit... there isn't a simple text type tiled background example to be found... but definitely review the ones that are there. Between those and dovoto's tutorials, you should be okay. If I were to give a very general explanation...

1. First, set a video mode. If you're fine with text type backgrounds for all 4 layers, Mode 0 works fine.
2. Next, you must have some VRAM allocated to backgrounds for the screen (engine) you want to display them on. The tutorials and examples cover this fine.
3. Use bgInit() or bgInitSub() to initialize a background layer. This is where things get hairy. Old tutorials do not use this function... in fact no tutorial that I know of explains it's use fully. It is part of a relatively new API for backgrounds written by dovoto. Looking at the docs and examples, the first few parameters are pretty clear, but the last two, the mapbase and charbase are tricky. Referring back to the dovoto's tutorial will be helpful here, as the concepts for them are explained well.
4. Load the map, tiles and palette to memory...

If there's anything you need more detail on please let me know. I admittedly stopped somewhat abruptly there...

Take care,

Ok, this is starting to make more sense to me, and with the help of the examples in the Devkit directory, I think the logic is starting to become clearer to me... the specsheet you linked to also helps a lot in putting stuff into context, so thanks =P

The one problem I have now is making sense of exactly what's going on in the all_in_one example. I can't properly see the logic behind that due to the fact that this "Pern Editor" seems to no longer exist, and due to the fact that it's not shipped as an executable (but as a .application file o_O), when I find the file in repositories, it fails to launch for some reason or another >_>

What I'm getting from it is...:

1. It sets the main 2D engine to Mode 5.
2. It sets the main 2D engine to read/write background data from Bank A in the VRAM.
3. It then initializes 3 backgrounds as 2 8-bit Text backgrounds and 1 Extended Rotation background (as per Mode 5), all using the same graphics offset meaning the same tiles.
4. Sets the priority so the 3 backgrounds show in the order required.

Now here's where I'm starting to get confused, because the raw files appear to no longer exist...

5. Loads the tiles out of an assembly file (seeing as MultilayerTiles is a label in the assembly file Multilayer.s)? What? Under what logic?
6. Copies the loaded tiles as the main background palette and of background 1's main graphics. This makes sense.
7. Loads the maps out of the same assembly file? Again, what?
8. Copies the map data to the respective background's map data area... That makes sense too.
9. Show the backgrounds that are to be shown (etc).

So basically, what's with the assembly files? I can take a guess that the map data layers are just indexes of the 8-bit tile palette, correct? But the tiles in the file itself... wtf o_O


On a second note, I read somewhere that Mappy and Tiled are good editors, and indeed the interface is rather nice... but there's no documentation on using them in Libnds... anywhere I could go for this?

I'd be a bit lost myself looking at the assembly files, I have no idea why those are used there. A simple bitmap image converted with grit to a map, tiles and palette would be much better for learning IMO.

There are different types for the map... but for a text background it is a array of unsigned 16 bit tile indexes. Definitely review this section of dovoto's tutorial which explains the entries in the map: http://dev-scene.com/NDS/Tutorials_Day_4

If I had a 256 x 256 pixel background, which is 32 x 32 tiles, then the map would simply be 1024 16 bit entries with character indexes and possibly information to vflip, hflip or define a specific palette. Usually, I would say it's most common to not specify a palette and just have the map be character indexes. So, for example, if your map has an entry in it of 10 and your charbase/tilebase set for your background is 2 (16KB * 2 = 32KB into whichever VRAM Bank you chose), then when the hardware goes to look for the tile graphics, it's going to start 32KB into the VRAM Bank, then 10 * 64 Bytes (the size of one tile) further to find the tile's graphic data for that map entry.

Said very shortly... the tiles, then, are palette indexes defining what color to show at each pixel of a tile.

AFAIK, big c/c++ arrays are slow to compile in gcc/g++. ASM arrays are faster to compile, so the image is stored in ASM files. why grit doesn't directly convert it to a .bin or .o file, I dont know.

Ok, I'm starting to get the hang of this now. The dovoto tutorial helps a lot, such a shame it's rather incomplete .

So it's possible to have tiles being maps of pixel colors, rather than palette colors (which Day 4 does)? Currently my tiles are made up of palette indexes, so... I'm interested in how to change that (can't see a BgType_Text16bpp...).

Also, that would lead me onto importing tiles via grit in the format above... I could do that, right?


And on a different note, I'm using the DMA to copy over the data, but something doesn't make sense to me. Why does only this work:
I mean, surely copying 64 over would mean you then have to go 64 forward to get to the next block? Copying 64 over then moving 32 forward and writing there would surely result in half the data being overwritten, right? o_O


Thanks again, and do forgive me for my probably mindless questions

dmaCopy's second parameter is a void pointer... but bgGetGfxPtr() returns a pointer to an unsigned short (u16*). I would gather that pointer arithmetic used on the return value would make it move 32*sizeof(u16), so 64 bytes.

There is no native 16 bit tiled format, I'm afraid. 16 bit Extended Rotation backgrounds are direct bitmaps and have only map data and no tiles. If you wanted to do tiles... you'd have to write the code yourself. I suppose the tiles would have to be just stored in main memory, and you could DMA a tile at a time (yuck) to create the background. Sounds messy but feasible.

vuurrobin wrote:AFAIK, big c/c++ arrays are slow to compile in gcc/g++. ASM arrays are faster to compile, so the image is stored in ASM files. why grit doesn't directly convert it to a .bin or .o file, I dont know.

Some of this can be better explained, but I've just woke up and my coffee has not kicked in yet...

ASM files (.s) are used to store the array of pixel data in a more effecient way than what the C/C++ compilers would produce, due to the ability of ASM to specify the data in the array in a direct one for one manor, where as the same C/C++ code can, in the worst case, double the amount of ram used for the array:

Take the following c code:

u8 text[12] = "Hello world";

This is converted to asm as a load of store this byte in that location (I can't remember the exact asm commands as the last time I did this it was for a GBA game I was working on), and the space it uses is sizeof( code Mode ) * 2 * 12 (I think I got this right, I'll do some test compiles later on, and post the results here). The code mode is 2 for thumb and 4 for arm mode (the DS uses both). if you put const at the start of the above code you would get something like this produced in asm (I think):

text:
.byte 'H','e','l','l','o',' ','w','o','r','l','d',0

Which is only 12 bytes, of course you whould not see the letters in the asm, it would be the ascii codes for the text.

The reason why grit does not produce a .o or a .bin file is down to simple economics of code debugging (I think, or at least it is to me). If you know what an image looks like on a screen, and you convert it to a 16 or 256 colour DS compatable image and want to confirm that everything is working correctly with the output which is easier to check? a .s file or a .o file?

In my current little project I'm spending a lot of time in a hex editor, which means that I'm going slightly insane with memory footprints of data, trying to get large amounts of data stored into a small area of memory with little overhead, and if these files were a .o file I could not do any confirming of data integrity after the conversion.

Oh and .bin files are ran though a program to convert them to a .s file which is then compiled into a .o file for inclusion in the final .nds file. So saving into a .bin file would just add an extra layer to the compile time.

Please note that everything said above is from my observations on how the devkitPro's GBA stuff used to work when the GBA was out, and may not be indicative of how the compilers work now, also I sometimes sprout a load of garbage so some garbage may be in there as well, I've already been told once by WinterMute that something I've said on the forums is wrong and he needs to correct it, but he never said what it was, or where it was...

Sylus101 wrote:dmaCopy's second parameter is a void pointer... but bgGetGfxPtr() returns a pointer to an unsigned short (u16*). I would gather that pointer arithmetic used on the return value would make it move 32*sizeof(u16), so 64 bytes.

OIC, yeah, that sounds correct.

There is no native 16 bit tiled format, I'm afraid. 16 bit Extended Rotation backgrounds are direct bitmaps and have only map data and no tiles. If you wanted to do tiles... you'd have to write the code yourself. I suppose the tiles would have to be just stored in main memory, and you could DMA a tile at a time (yuck) to create the background. Sounds messy but feasible.

Damn, so if I use Text, I essentially have to use the single 256 color palette for the entire screen? Drat. Although I guess 256 colors isn't that bad >_>

And in terms of Extrot backgrounds, they have only map data? How does that work? o_O

Well, you could surely do some kind of 16 bit tiled system... it would just take more manual coding of the system.

Ex-Rot backgrounds from that spec page (gbatek):

Of which, the "Extended" modes are sub-selected by BGxCNT bits:

BGxCNT.Bit7 BGxCNT.Bit2 Extended Affine Mode Selection
0 CharBaseLsb rot/scal with 16bit bgmap entries (Text+Affine mixup)
1 0 rot/scal 256 color bitmap
1 1 rot/scal direct color bitmap

Don't worry about the control register and bits, etc... Basically, an extended rotation background can either use 256 color tiles (basically like a text type background), be a direct 256 (8 bit) color bitmap or 16 bit bitmap. The latter 2 modes use no tile data.

With 8bit bitmap mode, the map is made up of 8 bit index entries from a 16 bit palette. With 16 bit bitmaps, the map is made up of direct 16 bit color values. When you initialize these types of backgrounds, the tilebase value is ignored and the mapbase uses a 16KB offset into memory instead of the 2KB offset used with tiled modes.

It's important to note, that a the pixel colors on a 16 bit background are 15 bit color and the 16th bit is an alpha value. If set (equal to 1) the color is shown. If not the color is not shown at all.