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 > mode 0 vertical scrolling idea

#35261 - esl - Wed Feb 02, 2005 7:36 am

I just want to get some input on this.

I am creating a game that requires vertical scrolling for an overall map(board) size of 256x2048 pixels (x,y). I am using mode0 with only one 256x512 background. Picture the board as being made of 8 256x256 pixel blocks stacked on top of one another. Both the top block and the bottom block must be unique but all of the blocks between them can all have the same exact look. What I decided to do is create three 256x256 maps in arrays. Map1(top of board), Map2 (the repeating middle sections), and Map3(bottom of board). When any part of the bottom 256x256 section can be seen on the screen I store Map2 to screen base block(SBB)0 and and Map3 to SBB 1. then as the screen scrolls vertically and the bottom 256x256 block goes out of view I store Map2 to both SBB 0 and SBB 1 and let them repeat as the background auto wraps on itself. and then just before the top 256x256 block comes into view of the screen (and while the screen is only showing what is stored at SBB 1) I send Map1 to SBB 0. All of the triggering of changing the data at the SBB's is caused by if statements comparing a Y value (that is add/subtracted to/from by pushing up or down, also changing the y offset of the background) to the vertical position I want the changes to take place at. This method seems to work fine when I use the keypad to adjust the yoffset for the background. I can scroll through the whole board and it looks fine. I am just wondering if there are any unforseen problems with this method.

Also I would like to create sprites that are positioned and move relative to the overall board rather than the screen. I haven't sat down yet to figure out how to work this on my own, but if you have any thoughts let me know.

Have a good one,

-e-

#35278 - Zhila - Wed Feb 02, 2005 1:29 pm

To tell the truth, that is one of the prefered methods (the other is to use a 256x256 background, and replace tile by tile each row while it is offscreen). As far as keeping sprites in sync with the background, just keep an overall scroll position of your virtual background, and apply it with an offset of the sprite relative to the virtual background, so it can be converted to an absolute screen position.
_________________
Current high scores on Super Mario 64 DS:
Shell Smash - 50230
Wanted - 140

#35364 - esl - Thu Feb 03, 2005 5:46 pm

Thanks for the post Zhila. It seems to me that the copying of individual rows of tiles would be quite a bit more complicated. Is there a benefit? I realize that 2k less space will be used in VRAM because it is only 256x256. Also is there enough time during VBLANK for the an entire Screen Base Block to be copied using DMA? The reason I ask is that it works well for vertical scrolling but drying to scroll sideways(just wrapping over the same 256x256 section I get some clipping. I shouldn't have anything to do with copying speed because just going sideways there is not copying being done.....so I guess I am wondering what the source of this clipping might be.

Scrolling right the image looks like this...

111 222 333 444 555 666
111 222 333 444 555 666
111 222 333 444 555 666
11 222 333 444 555 666 1
11 222 333 444 555 666 1
11 222 333 444 555 666 1
1 222 333 444 555 666 11
1 222 333 444 555 666 11
1 222 333 444 555 666 11

where the numbers should all line up in columns.

Again any thoughts would help alot.

Have a good one,

el
_________________
-e-

#35373 - sajiimori - Thu Feb 03, 2005 7:14 pm

Using 256x256 BGs saves a significant amount of VRAM when using all 4 backgrounds, it's easier to scroll both directions, and the performance is more consistent.

That said, if you don't mind using extra VRAM, and you don't have lots of other stuff to do in vblank, you can scroll both ways without too much trouble using 512x512 BGs. I can't think of a benefit of this method though.

Either way, make sure you hide the implementation and give it a minimal interface. There's no need to expose all that complexity to the rest of your program.