How did "Ballblazer" pull off fast, smooth, first-person, solid-model 3D on Atari 8-bits?

Question

I remember the first time I saw Ballblazer, the 1984 game, running on a friend's Atari 800. The split-screen 3d graphics and fast action blew my socks off.

Looking back, I get the impression there are some advanced 3d graphics techniques that appear to be used, but that would be either incredibly unique or impossible to achieve on mid-1980s 8-bit computers and consoles. The "rotofoil" players look like 3d polygonal modeling, which I am not aware of being used for any other fast-action 3d games on 8-bits. There were ground-breaking 16-bit games, like Arcticfox and Carrier Command that used polygonal modelling, but these games only managed wireframe 3d when ported to 8-bit machines. Another famous 8-bit game limited to wireframe was Elite. So, Ballblazer seems to be an early 3d standout with its solid, flat-shaded models.

Additionally, the 3d play field shows correct perspective at a high frame rate and looks like texture mapping to me. This almost has to be a programming trick.

Ballblazer was very successful, which led to many ports to other 8-bit systems. To my eye, the original Atari 800 and the Atari 7800 console versions look the best. The C64 version is also pretty true to the original.

How did Ballblazer appear to pull off these advanced 3d rendering techniques for 8-bit micros of the day, especially since all other games using these techniques only appeared on 16-bit systems years later? Are there any tell-tale signs of known programming tricks?

Answer 1

There are two elements:

• The background
• The sprites

The background is very straightforward:

The vanishing point never changes so you have one graphic with a checkerboard in perspective. That graphic takes 2 bits per pixel so that you have the 2 checkerboard colors and the edges of the field color. It just needs to be the width of the screen + 4 tiles (2 more checkerboard cells and 2 being the edge tiles).

so, if on a given scan line you can see 5 tiles, the line would be like this:

0 1 2 1 2 1 2 1 0

0 being the border color 1 and 2 being the tiles color.

The rest is simply horizontal scroll: since you can, in this example, display 5 tiles at once, when you are on the play field you do a fine scroll until you have moved to the next tile and then you jump back:

let's assume that the visible area is between brackets:

0....1[...2....1....2....1....2]...1....0
0....1.[..2....1....2....1....2.]..1....0
0....1..[.2....1....2....1....2..].1....0
0....1...[2....1....2....1....2...]1....0
0....1....2[...1....2....1....2....1]...0
0....1....2.[..1....2....1....2....1.]..0
0....1....2..[.1....2....1....2....1..].0
0....1....2...[1....2....1....2....1...]0
0....1[...2....1....2....1....2]...1....0

As you can see, you can loop it again and again to make the screen look as wide as you want. Once you reach the virtual edges, you just leave the color 0 be displayed. This is handled for free through the display list since you can change the display address and horizontal scroll registers automatically, per scan line.

The vertical motion is even simpler since it only requires to change the palette every scan line, essentially inverting the colors of the checkerboard pattern. All is needed is a lookup table for perspective and to know when to do the changes as the position determines where you start in the table (which just needs 2 more lines than what is visible as well, exactly the same way as the horizontal motion, since you're looping your start position between the 2 top cells). This can be done through the Atari 800's display list interrupts.

Regarding the sprites, there are stored at different sizes and orientations; knowing that you can double and quadruple their display size horizontally; also you can instruct the DMA to double up every line vertically as well, but this was not commonly used.

You can run your logic in 2d, all you need to do is a projection, which is essentially a division, to find the sprite size; The 6502 can't do divisions but since we're talking about a very simple case here (distance between the camera and the sprite on a single axis.. a subtraction), you can use a lookup table.

The game looks impressive, but it is technically very simple. If anything is not clear, just ask, I'll clarify the post.

Answer 2

The gameplay can be implemented without any 3D calculations (or very little, depending on your definition of 3D calculations):

• The checkerboard never rotates, so it can be drawn using affine segments and fills (y = ax + b); the players never get close enough to the edges (on the goal sides) for the vanishing point to be an issue. The checkerboard isn't texture-mapped, it's drawn using only two colours.
• The rotofoils are only ever shown in one of three angles, and are constructed with easily-scalable polygons (although "easily-scalable" would probably involve table-based calculations given the 6502's lack of mathematical prowess). The in-game rotofoils are much simpler than those shown in the title screen.
• The ball is always above the play field and is just a scaled, filled circle.

So basically to draw the 3D effects all that's needed is to figure out the scaling factor given an object's distance to the player. Redrawing the whole screen for every frame wasn't too difficult on the 8-bit Ataris.

Ballblazer's graphics and speed are still an impressive programming feat, but not as impossibly impressive as you seem to think.

Answer 3

A simpler way of putting the above very good explanations is... they cheated ;)

It's not proper 3D. If it was, you could face and move in something other than the four cardinal directions. Ever wonder why the movement feels so strange? It's because of that faked checkerboard motion as you move around the pitch. And that's the only "rendered" part; everything else is just flat sprites, drawn to look like 3D objects (again, the limited number of directions they can face massively reduces the data load of this precalculation), and moved and scaled by the machine's hardware (or on other platforms, just by CPU horsepower) on top of the playfield.

Answer 4

While all these answers make up part of the reason for the great screen refresh rate, there is one big item that actually makes the game work so smoothly, blitter chip. The 'Ballblazer' cartridge was unique out of all the carts that were produced. It was the only cart that had this chip incorporated into it. The blitter chip is/was basically a graphics processor unto itself, so the game would send the data to this chip and continue working as the blitter would process the info and manipulate it for the screen. That is it in a VERY basic form. This chip is used in a couple Full standing coin-op arcade machines that I repair. 'Robotron', 'Bubbles', 'Stargate', 'Sinistar' and 'Splat' from Williams Games all used this blitter chip. Unfortunately this great chip is no longer available so these games are not repairable if the blitter chip dies.