Best way to calculate road parallax in racing games?

[Vectrex2809]

Right now, I'm thinking about making a racing game. So far, I managed to implement a routine that can easily calculate the next frame of the road's parallax, like so

to

The only problem is that it takes a long time in CPU time to calculate the next frame, as you can see on the pic below (This is for 2 road frames at once)



This could potentially be a problem when the player encounters a sharp turn or gets sent to the other side of the road quickly, as it could be the source of slowdown (Not to mention road rendering takes a ton of CPU time too)

So I would like to know if there is a better way to calculate the road's parallax, making it possible to go from the pic on the left to the pic of the right directly.

to

[Memblers]

My first thought would be a look-up table, assuming you're not limited on ROM. If your scrolling covers 128 scanlines, then you'd have 128 entries in the table with the H value for each line. Then for the left-to-right position, duplicate the table for each step. In that case, 256 steps would make a 32kB table.

[Vectrex2809]

I thought about this actually, but I don't want to waste too much ROM space even though I'll probably end up doing it on an MMC3 because IRQs

[pubby]

I was thinking use a lookup table but only for slope values. That way it would be only 256 128 bytes and not 32k.

So I would like to know if there is a better way to calculate the road's parallax

It would really help if you were to describe your current attempt and how you want the parallax to actually behave.

[Vectrex2809]

So I decided to transcribe the scroll values onto a massive file and do as Memblers suggested. It seems to work fine - I ended up saying "*%$@ it" and going MMC3!

[tokumaru]

I was thinking use a lookup table but only for slope values. That way it would be only 256 128 bytes and not 32k.

Slope values would work, since the road is straight, not curved like in many teaching games. These values would have to be fixed-point numbers, but they can probably still fit in 8 bits. But you'd also need the initial scroll value for the topmost scanline, doubling the amount of space necessary for this approach, but that's still waaaay less than full lookup tables with values for every scanline.

[Drew Sebastino]

I can't help but feel that the road should get even smaller toward the top. It looks like it's as wide as the buildings.

[Bregalad]

What I did in the only demo I did who does that is use an exponential curve. The top scroll value is multiplied by a fixed-point constant and goes closer to zero each line. It works pretty well, although it's probably not the only way to do that.

Rad Racer does it all with lookup tables.

[mikejmoffitt]

I can't help but feel that the road should get even smaller toward the top. It looks like it's as wide as the buildings.

Certainly. The only other justification is the player is going around a small sphere or up a hill, forever.

[Drew Sebastino]

It's going around the entire planet, those buildings are actually moving backward.