Multiple extended BGs -- order of copying data

[Gmeeoorh]

Hi,

in the following small program I set up two bitmap BGs, scrolling them so I can see them side by side:

Code: Select all

#include <nds.h>
#include <stdio.h>
#include "gfx.h"
 
int main()
{
    vramSetBankA(VRAM_A_MAIN_BG);
    videoSetMode(MODE_5_2D);

    int bg1 = bgInit(3,BgType_Bmp8,BgSize_B8_256x256, 0,0);
    int bg2 = bgInit(2,BgType_Bmp8,BgSize_B8_256x256, 4,0);

    bgSetScroll(bg2,-SCREEN_WIDTH/2,0);
    bgSetScroll(bg1,SCREEN_WIDTH/2,0);
    bgUpdate();

    dmaCopy( gfxPal, BG_PALETTE, gfxPalLen );

    dmaCopy( gfxBitmap, bgGetGfxPtr(bg2), gfxBitmapLen*2 );
    dmaCopy( gfxBitmap, bgGetGfxPtr(bg1), gfxBitmapLen*2 );

    while(1) swiWaitForVBlank(); 
}

Now, while BG no.2 is fine, BG no.1 shows junk. Swapping the last two dmaCopy calls, both BGs are fine.
Can someone tell me why the order of copying data is important here?

[mtheall]

Why are you multiplying gfxBitmapLen by 2? grit already makes that a number of bytes, which dmaCopy takes as a parameter. With the order below, bg1 overwrites bg2 with data that is past the end of gfxBitmap. With them switched, you still write too far, but during the second dmaCopy, bg2 gets filled in with the right data (though it still writes too far at the end).

[Gmeeoorh]

Why are you multiplying gfxBitmapLen by 2?

Good question! ... Hm, maybe I thought about half words or something...
Anyway, thanks for the hint! A rather stupid mistake, and I thought it might be something interesting...