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.

Beginners > When to use REG_BG#HOFS and REG_BG#VOFS

#12442 - zdean - Thu Nov 13, 2003 8:07 pm

Hello I am trying my first attempt at programming on the gba. I am confused as to when to use the background offsets such as REG_BG2HOFS. It seems that if I was using a background such as 2 and wanted the scrollable area to be any larger then 240X160 I would need to write functionality to move the new offscreen onto the screen and the old onscreen tiles off of the screen effectively creating a scrolling effect. So when is it usefull to use the bacground offsets for scrolling? Can these to techniques be used together to simplify scrolling? Thanks!

#12443 - tepples - Thu Nov 13, 2003 8:23 pm

Background offsets are the only way to scroll a text background by less than eight pixels at a time. Most GBA games that scroll a text background over several screens seem to replace only those tiles that will scroll into view in the next frame, creating a "seam" visible in VBA's Tile Viewer but invisible in the composited screen. You only need one 32x32 tile map per background to make this appear seamless.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#12591 - zdean - Tue Nov 18, 2003 10:01 pm

Thanks! That is probably why my scrolling seems choppy since I am moving in 8 pixels at a time instead of 1 or 2, but when I try to use the background offsets to scroll the screen contents down and then write in new tiles the new tiles seem to move down as well and I get a yellow or empty space filling up the screen? Any suggestions. Thanks

#12595 - tepples - Tue Nov 18, 2003 11:29 pm

You have to write the new new tiles below the new tiles, and then the new new new tiles below the new new tiles. Please show a ROM or picture of what you're talking about; otherwise, I can only guess what you mean.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#12612 - zdean - Wed Nov 19, 2003 4:38 pm

OK, It would be very helpful to have someone else take a quick look at this, because I am not sure if I am approaching the problem the correct way. I can send you the ROM and source code. How should I send it? Thanks again.

#12616 - tepples - Wed Nov 19, 2003 6:02 pm

Do you have a web site? Many people post things on a geocities (or the like) account for the forum regulars to read.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#12624 - zdean - Wed Nov 19, 2003 9:29 pm

It's not much of a website, but I do have a url on geocities that I use to upload files to sometimes. It is www.geocities.com/azdenek. I uploaded two files test.bin which is the ROM and tutor.c which is the main source code file. The source code file is basically the tile tutorial from the pern project website with some changes to attempt large map scrolling. Most of the changes and functionality for the scrolling are under the GetInput function. Currently only the up key uses my attempt at scrolling so most of the code that I am working on is in that area. If it would help I can upload the other files tiles, levels and sprite data files. If you run the ROM you can see that moving up will scroll through the other maps, but the background is choppy looking and does not scroll as smoothly as the when I use the bg offsets. However, I can not seem to figure out any other way to move new tiles into the screen. It could be that my method of scrolling is way off from how it should be done.

#12625 - zdean - Wed Nov 19, 2003 9:31 pm

Correction to above. It seems the period I put at the end of the sentence containing my url page is throwing off the link try this instead www.geocities.com/azdenek

#12632 - sgeos - Thu Nov 20, 2003 12:25 am

tepples wrote:
Background offsets are the only way to scroll a text background by less than eight pixels at a time. Most GBA games that scroll a text background over several screens seem to replace only those tiles that will scroll into view in the next frame, creating a "seam" visible in VBA's Tile Viewer but invisible in the composited screen. You only need one 32x32 tile map per background to make this appear seamless.


I've seen how this works. Does anyone have or know of a good description of this algorithm? Psuedocode is helpful. I am not looking for something aimed at the GBA, a general description is better.

-Brendan

#12636 - yaustar - Thu Nov 20, 2003 1:11 am

I am confused a little, do you want to scroll the background layer or do you want to create a world that is larger then the maximum size layer (512x512 pixels)?

I am assuming the latter in which case the current method (from your bin) is wrong (although a damn good try).

I am working on thoery here so bare with me.

Basically when your characters reached the top, start scrolling the actual layer of the background. If you are using text backgrounds then they should wrap around nicely. Every eight pixels that you character moves, a row of tiles offscreen is edited for the contiuation of the map, then the row above it then etc.

Code:

new tiles drawn = @
old tiles = 0

00000000
00000000
00000000
00000000
00000000
00000000
00000000
00000000

character moves up

00000000
00000000
00000000
00000000
00000000
00000000
00000000
@@@@@@@@

and again

00000000
00000000
00000000
00000000
00000000
00000000
@@@@@@@@
00000000

and again

00000000
00000000
00000000
00000000
00000000
@@@@@@@@
00000000
00000000

you get the general idea.


The best thing to do would be to look at a game that does this effect like Sum of All fears and look at it in the map on auto update whilst moving.
_________________
[Blog] [Portfolio]

#12638 - sajiimori - Thu Nov 20, 2003 1:34 am

How about this? (Warning: untested, uncompiled, and possibly unclean)
Code:

#define SCREEN_WIDTH        240
#define SCREEN_HEIGHT       160

#define TILE_WIDTH          8
#define TILE_HEIGHT         8
#define TILE_BORDER_MASK    7

#define SCREEN_X_TILES      (SCREEN_WIDTH/TILE_WIDTH)
#define SCREEN_Y_TILES      (SCREEN_HEIGHT/TILE_HEIGHT)

// Size of physical tile map located in VRAM
#define PMAP_WIDTH      32
#define PMAP_HEIGHT     32

// Size of logical map (i.e. game world)
#define LMAP_WIDTH      2048
#define LMAP_HEIGHT     1024

typedef u16 Tile;

Tile* physical_map = HARDWARE_TILEMAP_ADDRESS;
Tile logical_map[LMAP_WIDTH][LMAP_HEIGHT];

// Physical map offset (in pixels)
int phys_x, phys_y;

// Logical map offset (in tiles)
int log_x, log_y;

scroll_right_one_pixel()
{
    // If we went off the edge of the physical map,
    // start back at the left.
    if(++phys_x >= PMAP_WIDTH * TILE_WIDTH)
        phys_x = 0;

    // If we crossed a tile border, copy in a new
    // column of tiles.
    if(phys_x & TILE_BORDER_MASK == 0)
    {
        // FIX: Doesn't check for edge of logical map
        ++log_x;

        // Find the top tile in the physical map
        int tile_x = phys_x / TILE_WIDTH + SCREEN_X_TILES;
        int tile_y = phys_y / TILE_HEIGHT;

        // Wrap
        if(tile_x >= PMAP_WIDTH)
            tile_x -= PMAP_WIDTH;

        // Copy strip of tiles from logical map to physical map
        load_tile_column(&logical_map[log_x + SCREEN_X_TILES][log_y],
                         &physical_map[tile_y*PMAP_WIDTH + tile_x]);
    }
}

load_tile_column(Tile* src, Tile* dst)
{
    Tile* end = src + LMAP_WIDTH * PMAP_HEIGHT;

    while(src < end)
    {
        *src = *dst;
        src += LMAP_WIDTH;
        dst += PMAP_WIDTH;

        // This is slow.  There should really be 2 loops
        // to avoid doing this check for every tile.
        if(src >= END_HW_TILEMAP)
            src -= PMAP_WIDTH * PMAP_HEIGHT;
    }
}


Edit: Hopefully makes more sense now.
Edit: Fixed more, shorter var names.
Edit: Fixed column loader to not run off end of hw map.

#12649 - zdean - Thu Nov 20, 2003 8:49 pm

I think I found part of my problem. I am trying to use background 2 in mode 2 which seems to be a rotation bg. Should I be able to switch now to mode 0 without having to change a lot of the display code?

#12650 - yaustar - Thu Nov 20, 2003 9:26 pm

actually you are using mode 1, but yes since it is 256x256, going to mode 0 shouldn't be a problem
_________________
[Blog] [Portfolio]