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.

Ballblazer screenshot

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?

  • 4
    I'm no expert on Atari, but the resolution seems to be quite low. They probably made use of frame swapping to achieve smooth background graphics, and hardware sprites for foreground objects. Elite (on the BBC Micro) could do neither of these since there were no hardware sprites and not enough memory for frame swapping. – Mick Mar 11 '17 at 18:49
  • 1
    Carrier Command has filled 3d graphics on the ZX Spectrum (and therefore probably the Amstrad) — youtube.com/watch?v=a1vts4wvw60 . And it's far from alone, e.g. see also youtube.com/watch?v=U5HOQc2BRxE or youtube.com/watch?v=ud3nXIbdJXY ; filled polygon 3d was perfectly achievable on 8 bit computers. Ballblazer isn't real 3d though. – Tommy Mar 11 '17 at 22:49
up vote 21 down vote accepted

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.

  • 1
    Great answer. I've been comparing the various ports using the video: youtube.com/watch?v=_tkwWD_BWWQ. Comparing the C64 and Atari versions, it really looks like vertical scrolling is where the C64 version fails. This makes perfect sense, since ANTIC display list processing is more sophisticated than what the VIC-II interrupts allow. But C64 does well moving in the horizontal dimension, because hardware for horizontal scrolling is similar to Atari's. Of course, the "lesser" 8-bit graphics machines fail in multiple ways. Still like Atari version, even over the ST port. – Brian H Mar 21 '17 at 0:15
  • 1
    The Atari 800 and Amiga have the perfect hardware to make this game! – Thomas Mar 21 '17 at 0:22
  • 1
    @BrianH if comparing and contrasting, also check out some of the home ports of Space Harrier. They're usually doing pretty much the same thing, except that now the camera is no longer at a fixed height. – Tommy Mar 21 '17 at 14:48
  • @Thomas or the other way round, the game was designed to take maximum advantage of the 8-bit Ataris’ capabilities (and the Amiga is the descendant of the 8-bit Ataris). – Stephen Kitt Mar 22 '17 at 14:37
  • yes, that's a good point; Wikipedia says that the game was Atari 8 bit first, so you're most likely right. I remember two similar games without the horizontal scroll: en.wikipedia.org/wiki/Trailblazer_(video_game) and en.wikipedia.org/wiki/Rainbow_Walker – Thomas Mar 22 '17 at 14:40

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.

  • Simplifying the polygonal modeling problem by limiting rotation to a few viewpoints and precalculating scale factors makes sense. I don't get what you are saying about the play field, though. It constantly rotates and changes to indicate your speed and direction, right? What sort of fast line draw and poly fill is at work there (note the anti-aliasing)? – Brian H Mar 12 '17 at 17:24
  • 1
    The play field just shifts left-right, the checkerboard is always built from trapezoids with horizontal lines. (So it would actually be possible to build the display with a line-scanning algorithm, no polyfills involved.) On the original hardware there is no anti-aliasing (see this video), although CRTs would have smoothed things out a little. – Stephen Kitt Mar 12 '17 at 18:35
  • 3
    To clarify the “shifts left-right” claim somewhat, the angles change, which involves some calculation, but it’s just a “line to the vanishing point” calculation — no 3D matrix multiplication and projection involved. The horizontal lines’ position can probably be determined using the same scaling adjustment as the rotofoil and ball. – Stephen Kitt Mar 12 '17 at 18:57
  • You can even just store it as a lookup table. For each line, have pre-calculated (i) start value; (ii) slice length, both in a suitable fixed point scheme. At the left, draw (slice length - start value) pixels. Then repeatedly draw runs of slice length pixels until you exit the right. If you want to move the floor 1/16th of a square to the right, run down and add 1/16th of slice length to start value. All just adding and single colour fills. You can even pretty easily difference two frames and do the minimal amount of work to modify an existing draw to the next. – Tommy Mar 12 '17 at 23:03

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.