Uzebox Forums

since i can't find a good tutorial on how scrolling works.

Really, we don't have anything on the wiki??

i can't find anything.. :/ (or it might be me not looking further than my nose)

jangoolee wrote:The result is consistent frame rates and perfectly smooth scrolling. ..... Keith thanks a bunch for this super easy to follow tutorial/explanation.

Geezz, those pathetic spammers think they are getting more clever? Before they were recycling quotes for this forums and now they think we won't notice nonsense coming from other forums?

Anyway, interesting it spammed this topic since there's news on this...Lee stated a pretty in-depth tutorial on the subject! http://uzebox.org/wiki/index.php?title= ... g_Tutorial

Bummer about the spammers, but hey, a good scrolling tutorial! The general info on how things worked was there but having a nice, easy to follow How To that ties together the different elements is definitely an improvement

I will randomly chip away at this as I get time. Basically it's building the example programs to demonstrate the different techniques that takes time. Without them, I fear it is not very friendly unless you already know how to scroll and are just looking for the Uzebox specific parts. I want the example code to eventually just plug into a program, and be a near optimum way to do things so no one has to reinvent the wheel. I've written fun little screen rendering programs on Uzebox for a few classic games(Zelda,SMB,CV). The classic ways to compress data will be in an advanced tutorial, they are not soft and fluffy nor covered in sunshine and rainbows, but they are not impossible to understand. I actually hope none of that will be necessary and we can find some way to make a 4 way scrolling engine that works off the SD/SPI ram saving big amounts of flash space. Then we can have some "ultimate" way to do scrolling that is best for any game.

I have no real numbers, just experience when I made a zelda mockup, that just shifting all vram over 1 column or row takes a ton of free cycles and can flicker if the rest of your drawing takes some time(like decompressing map data). I guess it might only apply to something where you use mode 3 with no scrolling, and do full tile scrolling. You can just let vram wrap in mode 3 with scrolling..if I remember right, to be honest I never did it in this efficient way yet, only the update entire vram way...Still there might be some uses I can't think of right now.

Alec, do you think it would be useful for the kernel to have built in assembly routines for stuff like that? I could see something like: and cases for UP,DOWN,RIGHT as well. Leave it to the main program to fill in the row or columns according to their data. Maybe it should just be written game specific?