gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Console on Background

#162534 - crazycrow - Thu Sep 04, 2008 4:28 pm

Hello,
I have another problem with the DS dev.
I have my 2 BG working, but I didn't manage to activate the console on it.

I activate BG0, BG2, BG3, but BG0 is fully corrupted.

Here is my code :


Code:

vramSetMainBanks(VRAM_A_MAIN_BG_0x06000000, VRAM_B_MAIN_BG_0x06020000,VRAM_C_SUB_BG_0x06200000 , VRAM_D_LCD);

videoSetModeSub( MODE_5_2D | DISPLAY_BG0_ACTIVE | DISPLAY_BG2_ACTIVE | DISPLAY_BG3_ACTIVE);

    SUB_BG0_CR = BG_MAP_BASE(31) | BG_PRIORITY_1;
    SUB_BG0_X0 = 0;
    SUB_BG0_Y0 = 0;

    SUB_BG2_CR = BG_BMP8_256x256 | BG_PRIORITY_2 | BG_BMP_BASE(0);
    SUB_BG2_XDX = 256;
    SUB_BG2_XDY = 0;
    SUB_BG2_YDX = 0;
    SUB_BG2_YDY = 256;
    SUB_BG2_CX = 0;
    SUB_BG2_CY = 0;



    SUB_BG3_CR = BG_BMP16_256x256 | BG_PRIORITY_0 | BG_BMP_BASE(3);
    SUB_BG3_XDX = 256;
    SUB_BG3_XDY = 0;
    SUB_BG3_YDX = 0;
    SUB_BG3_YDY = 256;
    SUB_BG3_CX = 0;
    SUB_BG3_CY = 0;

consoleInitDefault((u16*)BG_BMP_RAM_SUB(31), (u16*)CHAR_BASE_BLOCK_SUB(0), 16);

drawImageOnBG3(); // copy 256*192 pixel and the pal
drawSquareOnBG2();// square of 50x50 on top left



The Background 0 is corruped, but seem to be a tileset

Have you an idea ?

Thanks

#162540 - Cearn - Thu Sep 04, 2008 6:39 pm

Many parts of VRAM overlap. BG_TILE_RAM (=CHAR_BASE_BLOCK), BG_MAP_RAM (=SCREEN_BASE_BLOCK) and BG_BMP_RAM all point to 0600:0000 (and their sub-screen variants to 0620:0000). In this case, BG0 and BG2 both start at block 0, causing the console tileset to be overwritten.

You're also overwriting the console's map. The BMP and CHAR blocks are 4000h in size, and the SCREEN block 800h, so screen-block 31 is at the back of bmp/char-block 3. Since a full-screen 16bpp bitmap uses six BMP-blocks, BG3 covers the console's map and probably runs out of allocatable sub-VRAM as well (VRAM_A-D can contain 8 bmp/char blocks, and you seem to be using 9).

crazycrow wrote:
Code:
consoleInitDefault((u16*)BG_BMP_RAM_SUB(31), (u16*)CHAR_BASE_BLOCK_SUB(0), 16);
The macros for map memory are SCREEN_BASE_BLOCK_SUB and BG_MAP_RAM_SUB. BG_BMP_RAM_SUB is for bitmaps and points to an entirely different region of VRAM.

#162570 - crazycrow - Fri Sep 05, 2008 10:29 am

If I Have understand, when I display the BG 3,
I use :
Code:

dmaCopy(menubgBitmap, (uint16 *) BG_BMP_RAM_SUB(0), 256*192);
dmaCopy(menubgPal, BG_PALETTE_SUB, 256*2);


I overlap the memory where Default Font is Saved.

If I changed the Start of the console TileSet to put him at the end of the VRAM it may work ?

I calc that :

BG2 : 50px X 50 px X 16bits = 4,9 Kib
BG3 : 256px X 192px X 8 bits = 48 Kib
BG0 : Heuu , I don't know

if all is in VRAM_C , which can contain 128 Kib, all can be placed

Tell me if Im Wrong

PS: sorry if I don't speak well english but i'am french

#162585 - Cearn - Fri Sep 05, 2008 2:27 pm

I think there are several conflicts here.

This seems to be the arrangement from the code you've shown here:

BG0 : 256x256@4 tilemap (the console). Char-base=0, Map-base=31
BG2 : 256x256@8 bitmap (the square). Bmp/Char-base=0.
BG3 : 256x256@16 bitmap (the menu). Bmp/Char-base=3.

However, this does not seem to correspond with what you're saying.

crazycrow wrote:
If I Have understand, when I display the BG 3,
I use :
Code:
dmaCopy(menubgBitmap, (uint16 *) BG_BMP_RAM_SUB(0), 256*192);
dmaCopy(menubgPal, BG_PALETTE_SUB, 256*2);


This would seem to indicate that you're using BG3 for a full picture, but that it's a 8bit picture instead of 16bit, and that uses bmp-base 0 instead of 3. Are you confusing BG2 and BG3 ?

But yeah, part of the problem is that menubgBitmap would overwrite the console's tiles.

crazycrow wrote:
I calc that :

BG2 : 50px X 50 px X 16bits = 4,9 Kib
BG3 : 256px X 192px X 8 bits = 48 Kib
BG0 : Heuu , I don't know

if all is in VRAM_C , which can contain 128 Kib, all can be placed

Tell me if Im Wrong

You're wrong :P

A 256x192@8 bitmap would take 48KiB, but right now BG3 is initialized as a 16bpp image, which uses twice as much. Also, even though the rectangle you're drawing is 50x50, the bitmap you're drawing on is still the full size of the screen. Actually it's even bigger than that (256x256) but a 256x32 area is outside the screen so that part can be used for other purposes. If you want a 256x192@8 and a 256x192@16 bitmap to be free of overwrites from other sources, you need at least 48+96 = 144 KiB.

If the menu is not too complicated you can try using a tilemap for it instead. Identical tiles will be reduced to a single tile, which can result in considerably lower memory-use.

Perhaps it helps to look at the VRAM use graphically. Each 128 KiB VRAM-bank has space for 8 char/bmp blocks. Each of these contains 8 map blocks. The console uses 256 tiles (half a block) with on a single map. A 256x256@8 bitmap uses 4 blocks, but one is obscured so technically you only need 3. For a 16bpp bitmap, the figures are 8 and 6. With the settings in the OP, this gives the following layout:
Code:
128 KiB (8 char/bmp blocks) of VRAM
'*' for real use
'+' for outside the screen

    | CBB 0  | CBB 1  | CBB 2  | CBB 3  | CBB 4  | CBB 5  | CBB 6  | CBB 7  |
----+--------+--------+--------+--------+--------+--------+--------+--------+
BG0 |****    |        |        |       *|        |        |        |        |
BG2 |********|********|********|++++++++|        |        |        |        |
BG3 |        |        |        |********|********|********|********|********|********
    +--------+--------+--------+--------+--------+--------+--------+--------+

Notice the overlaps here; those are the problems. The key here is to shrink and shift the rows until it fits.

#162590 - crazycrow - Fri Sep 05, 2008 3:05 pm

your rigth , I am confusing the 2 BG.

BG 3 is display in BG_BMP_RAM_SUB(3)
BG 2 in BG_BMP_RAM_SUB(0)

The solution would be to display the Square with the 8 Bits System ?
Code:

    | CBB 0  | CBB 1  | CBB 2  | CBB 3  | CBB 4  | CBB 5  | CBB 6  | CBB 7  |
----+--------+--------+--------+--------+--------+--------+--------+--------+
BG0 |*****   |        |        |        |        |        |        |        |
BG2 |        |********|********|********|++++++++|        |        |        |
BG3 |        |        |        |        |********|********|********|++++++++|
    +--------+--------+--------+--------+--------+--------+--------+--------+


but , if I do that, the Square color is a pointer to the Palette, it's right ?

Thanks a lot to spend your time with a noob as me even if I am a Profession Developer, but in J2ME and I have some difficulty to return in C++ and the DEV DS.

#162592 - Cearn - Fri Sep 05, 2008 3:22 pm

crazycrow wrote:
your rigth , I am confusing the 2 BG.

BG 3 is display in BG_BMP_RAM_SUB(3)
BG 2 in BG_BMP_RAM_SUB(0)

Right. That clears up that then.

crazycrow wrote:
The solution would be to display the Square with the 8 Bits System ?

Yes ... and no. You can try adjusting your rectangle routine to work with u8 instead of u16, but you might be unpleasantly surprised at the result thanks to a well-known quirk in GBA/NDS VRAM (note: That's a GBA reference, but the concepts are applicable to the DS as well)

crazycrow wrote:
Code:

    | CBB 0  | CBB 1  | CBB 2  | CBB 3  | CBB 4  | CBB 5  | CBB 6  | CBB 7  |
----+--------+--------+--------+--------+--------+--------+--------+--------+
BG0 |*****   |        |        |        |        |        |        |        |
BG2 |        |********|********|********|++++++++|        |        |        |
BG3 |        |        |        |        |********|********|********|++++++++|
    +--------+--------+--------+--------+--------+--------+--------+--------+


but , if I do that, the Square color is a pointer to the Palette, it's right


I think that layout would work, yeah. The color in a paletted image isn't a pointer, but an index. A pixel-value with the of 31 (0x001F; normally red), for example would use the color in BG_PALETTE[31], which need not be red at all. That's probably what you meant to say, but since "pointer" has a specific meaning in C the difference is important.

#162595 - crazycrow - Fri Sep 05, 2008 4:22 pm

I have another problem when I change
SCREEN_BASE_BLOCK_SUB(31) to SCREEN_BASE_BLOCK_SUB(0)

There are many line from top to bottom.
but with SCREEN_BASE_BLOCK_SUB(31), I have nothing like that.

#162597 - Cearn - Fri Sep 05, 2008 4:46 pm

SCREEN_BASE_BLOCK_SUB(0) overlaps CHAR_BASE_BLOCK_SUB(0), so you'd have tiles and the tilemap at the same spot. But the font only takes up half the block, so you could place the map at the back of char-base 0, rather than the front. I think screen-blocks 4 through 7 are still safe.