How To Create Smooth Scroling Tilemap

[Job the GameQuitter]

You'd need to know about the LCD before I can fully explain. In short, to output the gbuf you need to copy every byte in it to the screen. However, between copying you need to wait a little bit more than 60 cycles (or 100 if you have a SE running in fast mode). Now, some of those clocks are used because you need retrieve a new byte and all, but most are wasted. But with some intelligent programming you could use those wasted clocks for scrolling.

But this is all relatively advanced, I don't recommend trying to use it unless you fully grasp both tilemapping and the way the LCD driver works.

[omni]

So that means every time you write a byte to screen, you need a delay before you can write again?

Does anyone have any tutorials on direct LCD communication? I already have
ASM in 28 days and I am reading it ,as well as the manual or something similar to it for the Toshiba T6A04A. Anything helpful in the manual?

Ps whats a dummy read?

[Job the GameQuitter]

It means that the first time you IN A,($11) you get a garbage byte instead of the byte you want. So that's called the dummy read.

[omni]

So would direct LCD communication be more effective than copying to buffer and bcall(_grbufcpy)? Seems to me that it isn't since you have to wait 60 cycles between writing.

[Job the GameQuitter]

Actually, bcall(_grbufcpy) ALSO waits 60 cycles between writing. And yeah, it would be faster, but you would see the screen build up as you output one sprite after another, which is ugly to look at. But if you only need to update one byte at a time anyway it would be sickeningly faster. For example, try my Langton's Ant program. The first only modifies one byte at a time on the LCD, so it's speed will knock your socks of.

Anyway, back on topic, did you find out what you needed to know about smoothscrolling?

[DigiTan]

You seem to have this display controller stuff well-researched, Job! I was wondering: are there any in-depth LCD drawing articles out there? And what do you make of the Blue! programs released a while back?

[Job the GameQuitter]

All my knowledge of the LCD display comes from the 28 days tutorial . So you can check it out yourself quite easily. And those blue programs can damage your LCD screen, so don't use them.

[Dwedit]

_grbufcpy sets the display mode to horizontal, rather than vertical, so there is more lag as it draws the screen row by row. Compared to say...ionfastcopy, which draws the screen column by column.

Column by column is faster, because there are less times to change the column than times to change the row when doing it row by row.

[b__]

Aren't there more columns than rows?

[Darth Android]

yes,96 colums, 64 rows

[Dwedit]

12 columns, 64 rows...

not 96 columns. (column = byte wide)

[Darth Android]

ah, columns of bytes, not pixels.
then no, there are more rows

[Job the GameQuitter]

And on top of that, _grbufcopy uses a delay that's bigger than fastcopy.

[omni]

Job:
Alright I'm pretty sure I got the help I needed. I just need to experiment and read up on LCD communication. Hopefully I will make a smmmmooooth scrolling routine.

[b__]