#121930 - Elite Beat - Thu Mar 15, 2007 8:44 pm
I'm trying to make a scrolling background for a platforming game, that will move up/down/left/right with the user's input. I've experimented with several experimental methods and read a lot on these forums, but nothing really answers my questions. On one topic I saw that you could have more than one 256x256 background, and then display these at the same time to create the illusion that you have one really big background (that scrolls). I'm using Mode 2, and fragments of knowledge from some tutorials but mainly http://www.webbesen.dk/gba/default.asp, which uses Mode 2. So the main things I'm asking are (and in the simplest terms possible):
1. How do you scroll backgrounds (using the way of drawing backgrounds on http://www.webbesen.dk/gba/default.asp)?
2. How do you "stitch" backgrounds together?
3. How do you incorporate these two into one universal big scrolling background?
I'd appreciate any help you give to me. Don't forget I'm a total n00b. Thanks.
#122041 - tepples - Fri Mar 16, 2007 6:57 pm
GBA display mode 2:
BG2: rot/scale, 256 tiles of 8x8 pixels 256 colors, map size 16x16 to 128x128 tiles
BG3: rot/scale, 256 tiles of 8x8 pixels 256 colors, map size 16x16 to 128x128 tiles
Is there a reason that you need rot/scale functionality on these layers in your platform game?
The basic idea is to calculate what column or row of tiles is going to become visible the next time the screen scrolls and then draw those tiles to the map.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#122043 - sgeos - Fri Mar 16, 2007 7:11 pm
Paper, pens and docs are a good way to get your head around this stuff.
Do one thing at a time. First figure out which "bg map" to draw to. Then figure out which cell in that map you need to draw to.
-Brendan
#122226 - Elite Beat - Sat Mar 17, 2007 11:23 pm
I get what you're saying (and no I don't need to do rotation and scaling), so how would using the code below, would you draw a background at a certain coordinate, would loop start off as a higher number?
| Code: |
for (loop = 0; loop < 256; loop++) {
BG_PaletteMem[loop]=bgPalette[loop];
}
for (loop = 0; loop < (120*160); loop++) {
FrontBuffer[loop] = bgData[loop] ;
} |
#122298 - Cearn - Sun Mar 18, 2007 3:10 pm
| Elite Beat wrote: |
I'm trying to make a scrolling background for a platforming game, that will move up/down/left/right with the user's input. I've experimented with several experimental methods and read a lot on these forums, but nothing really answers my questions. On one topic I saw that you could have more than one 256x256 background, and then display these at the same time to create the illusion that you have one really big background (that scrolls). I'm using Mode 2, and fragments of knowledge from some tutorials but mainly http://www.webbesen.dk/gba/default.asp, which uses Mode 2.
|
The crash course uses mode 4, not mode 2. I think you may have confused the background number (which will be 2 for mode 4) with the mode. Mode 2 is a tiled mode.
| Elite Beat wrote: |
So the main things I'm asking are (and in the simplest terms possible):
1. How do you scroll backgrounds (using the way of drawing backgrounds on http://www.webbesen.dk/gba/default.asp)?
|
You don't. Well, you can scroll them (using REG_BG2X and REG_BG2Y), but it wouldn't do you much good because it'd just move the background off-screen a bit. If you had to use mode 4 in a scroller, you'd have to redraw the whole screen using a larger bitmap for the source data, but at an offset. The GBA isn't fast enough to do this.
The majority of the games out there use mode 0, which uses tiled graphics, rather than bitmapped graphics. For more on these, see tonc, in particular chapters 7 and 9.
| Elite Beat wrote: |
2. How do you "stitch" backgrounds together?
3. How do you incorporate these two into one universal big scrolling background?
|
As tepples, you don't need to use multiple backgrounds to scroll around a map bigger than the allowed BG sizes.
The standard size of a tiled BG is 256x256 pixels, or 32x32 tiles. The screen can show a rectangle of 30x20 tiles. You can use the registers REG_BGxHOFS and REG_BGxVOFS to indicate where to draw from, effectively scrolling the background. For example, if you set REG_BGxHOFS at 16 (pixels) the first two columns on screen will be columns 2 and 3 of the map (tile columns, that is. Tile column 2 corresponds to pixel-column 16). At the right edge of the screen you'll see bg columns 30 31.
The thing about tiled background is that they wrap around at the edges. So if you scroll further, say, REG_BGxHOFS = 32, the left of the screen will be column 4, but the right-most columns will show bg columns 0 and 1. It would have been columns 32 and 33, but due to the wrap-around the columns will be shows at modulo 32, and 32%32 = 0 and 33%32 = 1.
The idea behind scrolling bigger maps is to update the bg columns 0-31 with data of columns 32 and 33 from the source map just before they should become visible.
Tonc has several demos that shows the wrap-around in action, you might want to look at them. There's also a demo called 'bigmap' in the lab that shows how to do what I've just talked about. I just haven't had time to write a discussion on it. Run the demos in VBA, open up the map viewer and set it to automatic update and see what happens.
#122503 - Elite Beat - Mon Mar 19, 2007 9:32 pm
Thanks! I'll work my way through this soon.
#129773 - Karatorian - Sat May 26, 2007 3:08 pm
The method I'm considering using is as follows, I haven't implemented it yet, but it should work.
Split your large map into 32 by 32 tile sections. As the screen size is only 30 by 20, no matter where you are on the map, you will veiw (at most) portions of 4 of these sections. Use a single 64 by 64 tile map that has the current four sections you need. As you scroll into a new section, rebuild the map using the four sections you require.
Hope this helps.
#133434 - thegamefreak0134 - Fri Jul 06, 2007 5:25 am
There is a problem with this solution however. Since you have to rebuild all 32x32 tiles of a map every time you decide to "redraw" a section (and because with diagonal movement, the logic could very likely decide to draw 3 sections in one frame) your CPU usage will spike a fair bit more than if you are only drawing the 10 or so tiles at the edge of the screen. This method would be most effective in a zelda-ish game with multiple non-scrolling rooms, but I think it would cause a complex game to "glitch" randomly as new sections needed to be drawn. The regular method is easier on the CPU, although granted you do draw things more often. So depending on the style of game, I could see both being used.
-gamefreak
Board members, feel free to correct me if I'm mistaken, it's been a while since I worked with a gba.
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]