| |
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! |
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
http://cadaver.homeftp.net/rants/scroll.htm |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
When doing "stepped" 8-directional scrolling like you describe, I've always cheated: if necessary, adjust the char center as the scroll step begins, so that I know I will reach the char edge in a fixed number of frames. According to my tests it hasn't looked too unappealing, at least when it's a game and the player can't really pay attention to the scrolling only :)
Don't think there's a way around it if you want to shift the screen memory only once per step. |
| |
Bob
Registered: Nov 2002
Posts: 71 |
Yes its a bitch!
anyhow in double buffer you will suffer :) and prolly end up cheating with table speeds that avoids the unalignments of d016 & d011.
With a single buffer it is much simplier.. lets say having only chars for output..
then I would recommend a full copy of the data directly to the screen, and not using step scrolling.. the code is acutally much simplier and it is easier to calculate with sine... and is not dependent on anything and you can have much unalignment as you want ;)
doing this in bitmap is different... I am still figuring out this with doublebuffers...
with AGSP (Vsp + Crunchlines) it is a bit easier actually because you don't have the double buffer, (ok it is not that easy actually) , need to limit the speeds to 4 to avoind most of the problems, but then you have no alignment issue here. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
(4.5, 4.5)
actually not a bad idea. subpixel it. |
| |
Style
Registered: Jun 2004
Posts: 498 |
I dont actually understand the problem. Can someone explain? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: I dont actually understand the problem. Can someone explain?
Just read Cadaver's rant. |
| |
Style
Registered: Jun 2004
Posts: 498 |
Oh yeh, I geddit.
Just VSP/linecrunch. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
VSP+linecrunch comes with its own set of issues (sprite pointers, losing a a couple of rows at the top of the screen), but I was thinking that a single char of VSP combined with CSEL nuking two columns instead of one could effectively give you a 16 pixel x-scroll register (first time 38 column mode is more useful than 39 :P )
I think that means that, as long as you always take a few frames to transition from dx=1 to dx=-1 and a few frames to transition from dy=1 to dy=-1 you can then defer any coarse x movement until you've finished with the last coarse y movement
Of course, as Cadaver's rant pointed out, if you just decide every 8 frames what you're going to be doing for the next 8 then you avoid all that arsing about, and never have to do a horizontal and vertical char move in sequential frames; it's just a straight diagonal hop whenever you cross both edges at once. Should be able to engineer a push-scroll to work with the same limitation, too. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
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. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Quote:Question though - what do you mean by "not free directional"?
It can only scroll in eight directions? |
| |
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. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
I drew a diagram, and now i understand the original problem a little better. Words to come later.
 |
| |
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. |
| |
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... |
| |
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. |
