How did old car games, using "sprite illusions", function on a technical level?

Question

Example: https://youtu.be/E9QJZSBpvg0?t=80

The road turns not only left and right, like in the classic Pole Position, but also goes up and down. Other than the cars and the road, there are numerous objects both on and off the road.

Obviously, they made some kind of 2D track map, placing out all the road pieces and objects, and the background is just a static image which moves to the left and right (also slightly up and down). And the car you play as is of course going around on this 2D map as a position, checking collisions with other objects and all that usual stuff.

But how exactly does the game decide what to paint on the screen? Does the car "cast invisible rays" in all directions facing forward, and then draw the sprites and road pieces if they are "seen" currently, with the right scaling and x/y position on the screen, starting from the back and going forward toward the car so that objects in front are drawn the last?

Is that really how it was done? Because it sounds just like "raycasting" to me, a technique used by Wolfenstein 3D, which barely ran on the SNES even in a very crude form. As far as I know, Top Gear didn't use any special chip inside the cartridge, and there were also many other games which probably used the same technique for the SNES.

I've always wondered how this was done. The fact that it's an "illusion" rather than "real environments" (as would be the case with actual polygons) makes this and similar games very interesting to me to think about.

It seems to me that this would've been very difficult to code and get to run smoothly, but this game is very smooth and fast, and some levels even include what looks like "real 3D" tunnels sometimes. (But they may also be some kind of sprite-trick illusion.)

It's easy to say, as a non-programmer, that these old car games just "go on rails" and "give you a headache". Well, it may be kind of true, but they certainly don't just randomly put sprites on the screen; it's clearly calculated from some kind of rigid math/algorithm, based on a well-defined "world". I'm wondering how exactly they determined how to place the sprites on the screen so precisely and in such an optimized manner as to run this well on such a (relatively) weak console as the vanilla SNES.

If it used "invisible rays", how many (roughly) of those did it cast per frame? Are we talking 25 or 320 or even more?

Answer 1

There's actually two layers of activity going on here.

First, for each scanline the machine can choose both which row of pixels to scan out, and where on the row to begin. This is the basis for drawing the scenery backdrop and the track. I believe the SNES has specific facilities for doing this which are much more convenient than on the 6845-family CRTC or the VIC-II.

The track itself is represented as a series of horizontal and vertical curvature values along its length - more like 1.5D than 2D, a simplification which really speeds up processing. These are interpolated and fed into lookup tables to determine vertical positions and row offsets per scanline, as well as how much the car should be pushed around (which the player has to counteract by steering).

On top of this row of pixels are the sprites representing obstacles and cars. If you go through the video frame by frame, you'll see that there's not a smooth animation of object size as it gets closer, but that it jumps through just a few sizes, and that the cars are only drawn from behind and from a rear quarter view. The motion of most objects is fast enough that it isn't really obvious.

The obstacles are listed in distance-along-track order, so the game only checks for the next one in the distance to come into view, and discards the ones that have fallen behind. There is thus a contiguous list of objects that are rendered every frame by passing them to the sprite engine.

Each object (obstacle or car) is simply placed at a height and horizontal offset corresponding to that of the track at the correct distance ahead, and the video hardware overlays them on the background pixels. There are no rays to cast, just a simple calculation per object.