Strange stripes in tile graphics on Nintendo DS

Question

I am working on a pong game for Nintendo DS. I use libnds to configure, and I came across very strange behavior. So far I have only tried this in emulators, but I use three different ones and they all exhibit this behavior, so I suspect that I am doing something bad.

The real problem is that when I use a background layer of 1 or higher for my tile graphics, I get weird stripes all over the layer. If I use background layer 0, the problem goes away, but since this is displayed last, I cannot draw it at the other level that I want.

My installation code:

void pong::setup_engine() { // Setup DS graphics engine. // ------------------------- videoSetMode(MODE_5_2D | DISPLAY_BG0_ACTIVE | DISPLAY_BG1_ACTIVE | DISPLAY_BG2_ACTIVE); vramSetBankA(VRAM_A_MAIN_BG_0x06000000); vramSetBankB(VRAM_B_MAIN_BG_0x06020000); u8 *tileMemory = reinterpret_cast<u8 *>(BG_TILE_RAM(1)); u16 *mapMemory = reinterpret_cast<u16 *>(BG_MAP_RAM(0)); int bg0 = bgInit(1, BgType_Text8bpp, BgSize_T_256x256, 0, 1); int bg1 = bgInit(2, BgType_Bmp16, BgSize_B16_256x256, 0, 0); //bgScroll(bg0, 256, 256); u16 *ptr = bgGetGfxPtr(bg1); for (int y = 10; y < 128*60; y++) { ptr[y] = 0xFFFF; } BG_PALETTE[1] = grey0; BG_PALETTE[2] = grey1; BG_PALETTE[3] = grey2; BG_PALETTE[4] = grey3; BG_PALETTE[5] = grey4; BG_PALETTE[6] = grey5; BG_PALETTE[7] = grey6; // 32 here is not 32 bytes but 32 half-words, which is 64 bytes. swiCopy(CORNER_TILE, tileMemory, 32); swiCopy(TOP_TILE, tileMemory + 64, 32); swiCopy(SIDE_TILE, tileMemory + (64 * 2), 32); swiCopy(MAIN_TILE, tileMemory + (64 * 3), 32); swiCopy(MAP, mapMemory, 32*24); } 

In the above code, I use level 1 for bg0, which is my mosaic graphic layer. This leads to the appearance of strange bands; if I were to change it to 0, it would look as expected:

 int bg0 = bgInit(0, BgType_Text8bpp, BgSize_T_256x256, 0, 1); 

Any ideas what causes the problem, and what is the solution?

Image of strange bands http://i41.tinypic.com/1oaern.png

Answer 1

Look at background.h for it to look like you are using BG1 and BG2. For mode 5, according to:

http://nocash.emubase.de/gbatek.htm

layer 0 and 1 are normal, and 2 and 3 are extended. I do not know what it means. If you just want to make regular tile material, you probably want bgInit 0 and 1 not 1 and 2.

You can change priorities at will, level 0 does not have to be on top of 1, etc. Look at the BGxCNT registers (BG0CNT, BG1CNT, ...) and the priority bits. Now, if the priority is a tie, then yes, the layer number determines who wins.

Answer 2

Two things. For example, interleaving is most likely a VRAM conflict, although it has been a while since I made DS dev the last. Double check where you copy your graphics and your tile data. In mode 5, two text backgrounds are used, which should behave the same if they are initialized in a certain way, so I'm not sure what happens there.

In any case, since you have two backgrounds, why not just set priorities in your registers to replace their z order? The default background is created only in a certain order, you can set priority so that the system draws them in any order.