How To Create Smooth Scroling Tilemap

[omni]

I would you create a smooth scrolling tilemap? Currently I can have a smooth scrolling sprite with no background, aligned tilemap rountine.

But I am stuck on how to create smooth scrolling tilemap. Would you create a bigger buffer than your data and display your buffer after shifting the bits?

[tr1p1ea]

You could do that but it would be memory intensive ... but then again it would be fast . Other ways to do it are to write a special tile drawing routine (sort of like a clipped sprite routine) to draw your tiles. You have a start x,y position for you tilemap .. and another start x,y position that would act as an offsett for your tiles. It is a bit more complicated but saves a lot of memory.

[omni]

could you go into a little more depth for your method? And whats clip?

[tr1p1ea]

A clipped sprite routine is a sprite routine that enables you to draw a sprite which is partially on/off the screen.

What you would do is have an offsett that points to the start of your tilemap in your Mapdata. Then you have another offsett which points to the starting position of the first 'tile'. You increase this offsett & redraw your tilemap and it will enable you to scroll. When the offsett reaches say 8, you reset it and increase the map-pointer respectively.

Sorry its a bit vague again (i dont have much time atm). There is a tilemap topic pinned with a routine in it ... you should check it out .

[Dwedit]

Crashman made a nice smooth scrolling tilemap routine, but it's very difficult to use. It's the fastest possible routine of that type.

[tr1p1ea]

Actually he also made a simple smooth scrolling routine that you should check out. Search ticalc.org for CrASH_Man.

[omni]

Does anyone know why crashmans routine is so fast?

[tr1p1ea]

1) Because he is a genius.
2) Because his methods arent what you would usually do. He has everytihng vertically aligned etc etc. A lot of thought has gone into it ... but there are some restrictions.

[JeePee]

tr1p1ea: why do you call everybody who has done something "useful" for TI a genius. (Probably just a habit, if so, would you mind to call me a genius too? )

[omni]

tr1ip1ea,does your method run at a decent speed? Or is it really slow, slow enough that it lags.

[tr1p1ea]

Well CrASH_Man is a genius ... he has done many awesome things.

The method i spoke of isnt the fastest around ... but it certainly wont lag.

[Dwedit]

I also made a fastcopy + tilemap routine, but it's slower then crashman's. If I tried to optimize it more, it would end up as a clone of his routine :)

Fast (but not fastest) vertical+horizontal scrolling, supports any number of tiles, has a normal plotsscreen. Those features make it slower than crashman's, which has a 32 tile limit, vertically oriented plotsscreen, and is about twice as fast.

[omni]

What if I shifted the screen after I had drawn the tilemap to screen aligned?

1.Draw the tilemap to screen aligned, dont acutally display it yet.
2.Then shift all the bits x times.
Where x is the 'shift counter'

[tr1p1ea]

yes you could do that, and of course you would have to fill in a missing row/column with an unaligned routine. But yes that would work nicely ... and reasonable fast too .

[omni]

I could fill the missing column with a HUD, but is there an instruction that
will but old carry into bit7 and shift all bits right and then bit0 goes to carry? I checked the instruction set, but no instruction does that.

[DigiTan]

This code will scroll an entire row by 1 pixel (intended for 96 pixel-wide screens. Naturally, you can modify it for bigger screens, or optimize the repetative code using a "DJNZ" loop:...

[Job the GameQuitter]

If you want the whole screen to scroll 4 pixels to the right/left at a time and don't have a tilemap buffer with the X/Y axis switched, you can also use the RRD and RLD instructions, which do the following:

RRD, before:
A = %XXXXaaaa
HL = %bbbbcccc
after:
A = %XXXXcccc
HL = %aaaabbbb

RLD, before:
A = %XXXXaaaa
HL = %bbbbcccc
after:
A = %XXXXbbbb
HL = %ccccaaaa

cycles: 18.

So you can shift 4 bits trough HL at a time at a faster rate that way, by simply doing

LD A,%0000abcd
LD hl,gbuf
RRD \ INC HL
RRD \ INC HL
etc.

where abcd = the four bits you want to shift in the left side of the screen. Scrolling the other way is done just like that, except you start at the other end of the buffer and use RLD \ DEC HL. It's not smooth, but it's an option.

Now, scrolling up/down with a regular gbuf is just a matter of LDIR-ing the screen. I'm working on an alternative (faster) method of scolling up/down using the Z-adress, which my fellow coders over at Maxcoderz lovingly nicked "Jobean scrolling" . Because of that I made three programs which demonstrate different approached to vertical scrolling, which you can find here here. They're not useful routines in practice, but maybe it'll help explain some concepts of scrolling vertically (although I suggest you don't try to use method 2 or 3, because one is memory-hogging, and the other complex as hell).

[Dwedit]

Shifting after drawing the the map is slow. Don't bother with stuff like that, just get the map drawn in one pass.
This old one I made takes almost constant time to draw the map, regardless of x scroll position.

[Job the GameQuitter]

Shifting after drawing the map can be fast, if you only draw the part that is being scrolled in each frame thereafter. You'd have to put the sprite and mask in a seperate buffer though, because you can't mask them on top of the tiles. If you did you'd have to redraw the whole map again. The masking of these buffers and the scrolling can be done minimal speed decrease, using the wasted clocks between outputting bytes to the screen.

[omni]

what do you mean by using wasted clock cycles?