devkitPro

Posted: **Tue Mar 29, 2011 10:51 pm**

Hi,

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

#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?

Posted: **Tue Mar 29, 2011 10:55 pm**

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

Posted: **Wed Mar 30, 2011 7:55 am**

mtheall wrote: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...

devkitPro

Multiple extended BGs -- order of copying data

Multiple extended BGs -- order of copying data

Re: Multiple extended BGs -- order of copying data

Re: Multiple extended BGs -- order of copying data