Variable Speed Vertical Scrolling - Elegant Solution Wanted!

[+therealbountybob]

Making the final few changes to Ramp Rage mainly on making it play nicely on NTSC...

 

Any suggestions (or code) for an elegant way of vertically scrolling with variable speeds?

 

What I have is the assember equivalent of a ton of IF THENs for about 6 different speeds:

something like

IF SPEED SLOW THEN

IF NTSC THEN ntsc code*

ELSE pal code*

...

 

*I'm using RTCLOK+2 and various VBILoopCounters with ANDs for periods to scroll or not scroll.

(Sometimes the PAL logic for the next faster speed is the same as the NTSC logic for the previous speed)

 

I feel this is taking up way too much space. Perphaps there is a table based way of doing this? If it's any help I have an NTSCFlag set which could be used for an table offset.

 

Thanks

[Rybags]

Use fractional maths in similar fashion as if moving sprites.

 

Velocity value stored in 2 bytes, high byte contains direction plus amount to move each VBlank.

Low byte contains value which is added to a working accumulator value, if it carries over then it also gets added/subtracted from positional value on that iteration.

 

Using such fractionals allows many speed variations from 1/256th, 2/256ths through to 254/256ths, 255/256ths.

 

If you're real fussy, you could do tables such that Pal and NTSC speeds are overall almost identical. But movement that isn't frame-exact can look jumpy.

[NRV]

Use fractional maths in similar fashion as if moving sprites.

 

Velocity value stored in 2 bytes, high byte contains direction plus amount to move each VBlank.

Low byte contains value which is added to a working accumulator value, if it carries over then it also gets added/subtracted from positional value on that iteration.

 

Using such fractionals allows many speed variations from 1/256th, 2/256ths through to 254/256ths, 255/256ths.

 

If you're real fussy, you could do tables such that Pal and NTSC speeds are overall almost identical. But movement that isn't frame-exact can look jumpy.

 

Yep, +1 to Rybags answer.

I do that in my Pad game for the movement of the balls, enemies and powerups, and with different movement values for NTSC and PAL (so they move at the same "speed").

The only problem could be that for small objects it probably looks better (unnoticed) than for the whole screen (your case).

But is by far the more elegant solution, forget all those if/then and counters.. just add two values every frame and update the scrolling/LMS's with the processed result.

 

For example, let's say that you move one scanline every frame in PAL, then your two values are 1 and 0 (decimal part).

Then you have a speed of 50 scanlines per second in PAL.

To replicate that speed in NTSC you need to move every frame a value equal to 50/60 (50 scanlines in one second or 60 NTSC frames).

So 0.83333 scanlines per frame, and your two values should be 0 and 213 (approx... is never going to be perfect for all cases with this method, but good enough).

 

(What I did was to take the decimal part ".83333" and multiply it by 256 to get a new "byte" from it.)

 

Obviously, you need to remember (accumulate) this 2-byte result from frame to frame.

 

Also you can now do some kind of smooth acceleration effects, no need to have just 6 different speeds.

[+therealbountybob]

Thanks for the replies, I'll have to study this more to understand things better.

 

I'm scrolling downwards only. I have a "speed" variable that I can use from ~1-64

 

Currently I have scroll speeds from something like

slow RTCLOK+2 ANDed with 7 (BEQ calls fine scroll)

... to ...

fast each VB plus an extra slow

so most of the scrolls are less than 1 per VB which might make things trickier?