Help with displaying background using NFlib and libnds.

[pansy_thoughts]

hello there,
so i've been working on a sort of demake or recreation of the Scott Pilgrim beat 'em up game for the DS, since i wanted to try out DS programming, and eventually kept adding things, until i had one character in scene in the first map of the game, with background music and complete basic mechanics and all:

and with what i've been busy lately, is to get the background to scroll like the actual game, but stumbled upon a VRAM limitation with Nightfox's lib, which assigns just 8 banks (~128 KB) for backgrounds per screen for both tiles and maps, as seen on this define:

/// Maxmimum number of VRAM blocks used for tilesets
#define NF_MAX_BANKS_TILES 8

/// Maxmimum number of VRAM blocks used for maps
#define NF_MAX_BANKS_MAPS 16

BUT for the scroll system that i want, i needed a little more than that, so i modified the lib to use more banks for tiles, and also set vram bank C to also upper screen main BG, which overall allowed me to have two 256 x 256 chunks loaded at the same time in screen.
the thing is, the first 2 chunks load just great (as seen on the previous screenshot, but when it scrolls and loads the next one, the graphics on that layer show glitchy:

without getting into much detail of how this system works, it just unloads the left chunk that is not visible, and loads the upcoming next one to the right (the one which appears bugged).
basically, it should load these two chunks on screen as it loaded the ones in the first screenshot, but it doesn't.

i tried manually wiping the adresses of memory of vram bank C (where the buggy chunk is loaded) using memset() before loading the chunk, suspecting it may be caused because of overwritten memory in the vram bank, which led to corruption, but doesn't seem to be the case:

memset((void *)0x06200000 + (NF_TILEDBG_LAYERS[screen][layers[RIGHT]].tilebase << 14), 0, NF_TILEDBG_LAYERS[screen][layers[RIGHT]].tileblocks << 14);
memset((void *)0x06200000 + (NF_TILEDBG_LAYERS[screen][layers[RIGHT]].mapbase << 11), 0, NF_TILEDBG_LAYERS[screen][layers[RIGHT]].mapblocks << 11);

i'm really looking forward to continuing this for fun, so i'll be reading any advice or request that you give me, regarding this or any other thing. thanks c:

 

[plasturion]

I came to the same point with my platform engine where I realized that 128kb is just not enough for the whole vram tilesets.
I see you that are doing some manual improvements on the registers and memory, I wonder if it somewhat counteract with
nf scrolling engine. If you want to check what exactly happens with vram tilebase and map there are some emu debugger add-ons in desmume or extended version of No$gba. This glitch at the bottom looks like memory conflict between already reserved area by nflib and I guess yours manual memory operations. Maybe this link also will be helpful https://mtheall.com/vram.html
I can't give you any recipe for your needs, but I'm looking forward for any nflib mod if you would like to share.

 

[pansy_thoughts]

thanks for replying! I'm honestly really new to this scene and have been using this silly project to learn more C/C++, and the set of things that involve working on a project.

as for the scroll engine, I noticed that for my purpose the NF function to scroll BG wasn't really optimal, because it wouldn't allow me to show each 256x256 chunk as a '''virtual''' (idk how to call it) 512x256 chunk, but with half of it empty, so that the other chunk could have the empty space of the other one (I hope I explained myself (?)).
when I tried this with the NF function to scroll, it would give me even more glitched graphics (of course, since I was treating a 256x256 BG as a 512x256).
so I made my own function that just sets the value of the scroll in each axis, to their corresponding scroll registers:

// main screen.
        switch(layer)
        {
            // update scroll registers of the used layer.
            case 0:
                REG_BG0HOFS = scroll_x;
                REG_BG0VOFS = scroll_y;
                break;
            case 1:
                REG_BG1HOFS = scroll_x;
                REG_BG1VOFS = scroll_y;
                break;
            case 2:
                REG_BG2HOFS = scroll_x;
                REG_BG2VOFS = scroll_y;
                break;
            case 3:
                REG_BG3HOFS = scroll_x;
                REG_BG3VOFS = scroll_y;
                break;

not the best, but found it worked better for my purpose than the NF function.

as for a NFlib mod, from what I have used from it in this regard, maybe I would make the NF_InitTiledBgBuffers() function take a parameter which tells it which mode to initialize the system: default (128 KB for BG), extended memory (192 or 256 KB for main screen BG at the cost of other VRAM bank(s)) and a shortened memory (64 or 96 KB for main screen BG), and so on.
I'm also just learning to use github, so I could maybe make a pull request on it later. not an expert on this stuff, I remind.

I will try that VRAM debug tool, but tomorrow since I'm tired lol. thanks a lot anyways!

Post automatically merged: Jul 13, 2025

so I basically fixed it
I basically stopped using melonDS since DeSmuME has WAY better debugging tools that I wasn't aware of.
and they let me see that the chunk itself wasn't glitchy, but the half that was supposed to be empty:

so I came up with a solution which is to basically set to index 0 the maps corresponding to those glitchy tiles, so they would appear as empty:

    // creates pointer to the position in memory where the maps begin to be stored.
    u16* map = (u16*)(0x6000000 + (NF_TILEDBG_LAYERS[screen][layer].mapbase << 11));

    // sets to 0 the positions corresponding to the next half.
    for(int i = 1024; i < 2048; i++)
    {
        *(map + i) = 0;
    }

which completely solved the issue:

(I need to fix that difference in color palette between the 2 chunks, but that's another story.

anyways, I'll be reading any suggestions about this project, if anyone wants to comment them.