Smooth scrolling tilemap?

[WikiGuru]

I was wondering if someone could go over the concept of a smooth-scrolling tilemap?

I have a few ideas on how they would work, but i'm not sure which way would be the best way to implement.

Idea 1: Have a screen buffer slightly larger than the display screen. To scroll up/down, the draw pointer is moved up/down 1 bytes. To scroll left/right, data is shifted right/left 1 bit.

Idea 2: Shift the current screen. Then, depending on which way the screen was shifted, draw the missing parts as defined by the tilemap.

edit:

after looking at this, it looks like he used idea 1 (i think, i can't tell). Out of curiosity, would idea 2 work better at all (in terms of memory, speed, or both)?

[asdf]

Well, idea 1 requires that you update the entire buffer each time you have scrolled a complete row or column, in addition to a few other things that aren't very efficient. I just checked it real quick, but it seems like what he did was have two variables, one to show the current map's aligned position, and one to keep track of how many pixels off it is from being aligned. When it shifts, he shifts the screen accordingly then fills in the gap, like your idea 2. The "temp" variable is just where he rotates the bytes to match the x/y offset. To shift horizontally, he fills the temp variable again with the offscreen sprite data then checks the bit that needs to be shifted in. If it is zero, reset the carry flag, if it is one, set the carry flag. The carry flag is then shifted into the screen.

There are certainly different ways to handle it all (for example, you can have the map routine handle the shifting if you want and then just update the x/y coordinates when moving about the screen). Really, just figure out what works best with how you want your character (or whatever is interacting with the tilemap) to navigate the tilemap.

[cjgone]

didn't read the above post but theres a few ways (srry just came back from some other place)

simplest way is to draw the tile map from an x and y coordinate that is at the top left of the screen. everything is drawn relative 2 this point

tiles are 8 pixels by 8 pixels, so an alligned tile map, there is 12 by 8 sqaures on the screen... if you scroll left and right, you'll get some more..

the top corner starts at 0,0 and you draw the tile map based on the top corner.. as you go right you increment the x cor and dec it going left... same for up \ down..

okay, so lets look at actually drawing the tile map.... if we have a tile map thats like 8 by 33 ( 8 down, 33 across... forget up and down scrolls atm cuz its the same concept as left\right), if the top coordinate was at 0,0 you would draw an 8x12 map onto the screen, all the tiles will be alligned, which means every 8 pixels, there is another tile and no tiles not fully draw on the LCD. So when is the tile map alligned? At 0,0 (x,y)... 8,0 16,0 ...so on and on... the pattern is 0,8,16,24,32... which is infact the width of each tile..

at 0,0, the tile on the top of the map is the 0th tile (aka first tile) at 8,0 the tile in the top corner is the first tile (aKa the 2nd tile).

i really cant explain the idea atm, but the tile in the top corner is the x coordinate divided by 8. so if the coor is 1,0 the top tile is the 0th, if its 5,0 its still the 0th,,, if its 10,0 its the first tile... in z80 division
0/8 = 0
4/8 = 0
7/8 = 0
8/8=1
12 /8 = 1 ... now we got an alligned map.. by using the top coordinate and diving it by 8 you can find what collumn the first tile is, which is the starting point for all the other tiles.

now we gotta do the offset.'

we use modulus to find the "offset", which is how far the tiles on the screen are shifted. at 0,0 the tile map has a 0 offset (all tiles alligned), at 1,0 the tile map is offset by 1 pixel... 2,0 = a shift of 2 pixels.... 8,0 = 0 shift.... so on so forth...

If you continue you'll see a pattern offset of 0,1,2,3,4,5,6,7,0,1,2,3,4,5,6,7... which is infact modulus 8.... To do modulus 8 in z80 quickly, you;d do "AND 07".... not explain why tho

So if each tile is a seperate tile drawn by putspriteCLIPXOR, you'd do something on the idea of "putspriteclip( x - OFFSET, y)".... IF there is an offset on the left or right not only do you need the 8x12 matrix, but their is infact a 13th collumn which must be accounted for when the map is unallgined.

generally, this is a slower way but way easier anyway. srry if this explanation sucked but oh well.

[Cryzbl]

[Liazon]

the major annoyance of this method is that you do need an extra buffer to hold the map, otherwise the sprites will leave artifacts because the buffer you're shifting will still have them. you then modify this buffer with your mapper and copy to the main buffer where you draw sprites.

extra rows in the buffer can be useful, because as you said, you can just change the starting row for your vertical shifts. I think Jim'e mappers do this too. extra columns not so much because you have to do multiple (ranging from 0 to 4) shifts for every byte in addition to the copy operation to the main buffer. without the extra column, you might just need to do 1 shift per byte, but like Cryzbl pointed out, this isn't too flexible unless you modify to allow more shift from the current position. extra columns force you to use the aligned positions to shift from. and if you shift 1 pixel per frame, each shift in one direction takes more time with extra columns.

[calc84maniac]

Actually, redrawing every frame is by no means slow. It allows you to have animated tiles, plus you don't have to worry about sprites messing it up for the next frame. I mean, just look at Project M. The tilemapper got over 40 fps there.

[Liazon]

i have a hunch, a tile scrolling (messuptiles) method?

[cjgone]

I'm using the fill-scroll method for my blobby project thing where i fill in the extra pixels on the edges after a shift and I don't think i'm getting anymore speed then calc84maniac up there with a tile by tile method.... not to mention the benefits of having a tile by tile drawing >.>

[Liazon]

one of the biggest bottlenecks will probably be the fastcopy. the delay/waits between outs is a lot of wasted clocks unfortunately. hence, the interlacing of LCD writing and buffer drawing in crash's and one of Jim's earlier mappers.

[asdf]

Redrawing the tilemap every frame is indeed slower, as you are either clipping every tile individually then drawing it on screen or drawing them all to a buffer and shifting the entire buffer, and, unless you are using a timer to keep things consistent or something else to maintain consistency, it will look choppy as you move because the screen will display much more quickly when it is aligned.

If you are planning on having a lot of animated tiles, however, redrawing the map each frame is a good way to keep the map speed consistent no matter how many animated tiles are onscreen.

[Iambian]

From experience, trying to fill in the gaps after a shift proved to be a lot slower than just redrawing the whole map from scratch. With what little I've done with regards to smooth scrolling tile maps, I've found that if the redraw is done by AND-ing two halves to form a tile, there's very little shifting involved in making the entire screen seem like it's moving. In fact, I've written a little routine that buffers all the shift and mask possibilities in a 16K chunk of that "extra" ram in the TI-83 Plus SE / 84+ calcs so that there is literally NO shifting beyond the initial buffering. Frame rates went through the roof with that method :)

Still. I'm against filling in the extra bits during a shift. It just uses way too much logic to be any faster than a total screen redraw.

[tr1p1ea]

I prefer to redraw the map each frame as well, mainly because of the animated tile payoff. Pre-rotating tiles (or just using a LUT) can give you a constant (and fast) frame rate no matter the xoffset.

[Cryzbl]

[tr1p1ea]

I never really like that approach to animated tiles for some reason. Have you thought about integrating fastcopy into your mapper?

[Cryzbl]

[calc84maniac]

As in, let the tilemap drawing code also output the previous contents of the buffer to the screen.

[Liazon]

basically, you send one byte of the buffer to the LCD, and then during the wait, you write one byte new data to the buffer. instead of wasting time waiting, you can use that time to do a consistent operation for ever one of those 768 bytes.

Jim did this, but I'm guessing tr1p1ea that you've probably optimized a lot?

btw tr1p1ea, do u integrate the LCD write and the buffer draw in Crystal Elements?

[tr1p1ea]

CrASH_Man's mapper (the one being used in sonic iirc) is a really good example of a highly optimised mapper. Jims rewrite of dwedits mapper is also a good example.

Liazon: Since mario is a grayscale game all the LCD interaction is required to be part of the interrupt and not the mapper.

[Cryzbl]

[Liazon]