[CSDb] - User Forums - Diagonal Scrolling

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Diagonal Scrolling

2016-05-25 22:49

TWW

Registered: Jul 2009
Posts: 545

Diagonal Scrolling

So I figgured I'd try my hands on doing a 8 directional scroll routine. Figgured it would be pretty straight fwd. but have done attemts in the past where I got lost in the code (dual screens buffer, edge buffers etc) so build a nice framework to handle IRQ sequencing, async, events etc. and looking really good.

hen a snag I didn't enticipate. 6 directions works perfectly fine but consider this:

1 8x8 picel character, where to place the center?

Obviously at (4,4), (4,5), (5,4) or (5,5) considering coordinates from 1-8.

But with diagonal scrolling it will not meet the 'edge' for $d016 and $d011 at the same time and it's all messed up unless I cheat (which is what I'll end up doing) by setting any of the formentioned coordinates as (4.5, 4.5) and the first move is to move into one of the four coordinates depending on direction.

So before going ahead and doing this, I wondered if anyone have solved this differently?

NB. It's not freedirectional and scrollspeed is 1 pixel pr frame.

EDIT1: Ignore

EDIT2: EDIT1 is crap!

... 10 posts hidden. Click here to view all posts....

2016-05-27 14:53

TWW

Registered: Jul 2009
Posts: 545

Quote: Question though - what do you mean by "not free directional"? How is the scrolling controlled, and what constraints can you place on it?

Also, how many cycles do you have free per frame for scrolling?

It might be a lot simpler just to chase the raster decrunching the entire screen from the tile data; should be easily under 25,000 cycles, so if you can spare 12k per frame then all you need to do is avoid the case where you clip the corner pixel of a char grid alignment for a single frame.

Not free directional I mean that the scrolling follows a fixed path (i.e. (4,4), (5,5), (6,6), (7,7), (8,8), (1,1), (2,2), (3,3) and then back to (4,4) again). It is not free to go 2 steps in X and one in Y f.ex.

Regarding the RTIME I use double buffering and the screen is scrolled by a task handler which runs outside IRQ so the RTIME is soaked up while hardware scrolling (plenty time available). Inside the IRQ I run a sequence handler which allows me to tailor each scroll-step and what to do when which structures and simplifyes the code a lot (at least for my head). However I also need to include color data scrolling which will have to be synced to the character shift and screen refresh and thus the raster chasing will be reserved for that and not for the gfx-copying.

2016-05-27 18:11

ChristopherJam

Registered: Aug 2004
Posts: 1409

I drew a diagram, and now i understand the original problem a little better. Words to come later.

2016-05-27 18:52

ChristopherJam

Registered: Aug 2004
Posts: 1409

So, diagram has centre at (3.5,3.5), which of course only lies on one of the two main diagonals, giving a single frame clipping an adjacent char when traversing the red lines (i suspect the green lines are the six cases referred to in the original post).

A radical suggestion: buy time by making the problem "worse!" Move the centre to (2.5, 2.5). Then whenever you follow a red track you spend three frames in the adjacent char, giving plenty of time for a second buffer flip. You also have three frames at the start of each path, as long as you decide where you're going next as soon as you arrive, or two frames if you only start work when you leave.

2016-05-27 20:39

TWW

Registered: Jul 2009
Posts: 545

CJ: Yepp, that would do it error free. Will cost two pulls for that particular line though so it will depend what else is going on. Will try it out and compare. Thanks for the tip!

Regarding VSP/Linecrunch I was not planning on doing that untill I wanted to do Bitmaps whenever I get around to do that...

2016-05-28 22:06

Firehawk

Registered: Aug 2011
Posts: 31

In QI (yes I know REU helps, but this is not the point here) I did a pre-processing of the movement tables so that I could start rendering immediately for the next char-position (while moving in $d016/$d011). I think this can be applied here also?
Depending on whether you're doing bitmap or font graphics, the only thing to consider is how many frames do you need to update the screen (this is how many soft-frames you need the movement to account for). Moving the data from cache to backbuffer can be done outside the IRQ, so you don't have to worry about music and other rastersplits while doing this.

edit: my point also is that no actual "scrolling" is needed, just do a recalc of where to fetch the source from, and update the entire thing.

Previous - 1 | 2 - Next

Refresh

Subscribe to this thread: