Why don't I see tile-based 3D graphics?

Question

As we know, tiles can make it quicker to update large portions of the display at once, as compared with a bitmap. To put, say a letter, on the screen, the Commodore 64 typically does two writes (the screencode and the attribute), but the ZX Spectrum typically does 9 (eight bytes which make up an 8x8 bitmap, plus 1 for the attribute).

Recently, a demo for the SEGA Genesis was released called Red Eyes. My understanding is that the 3D scenes were rendered on a PC, and some kind of program converted these animations to a tileset so that each frame can quickly be written into VRAM.

But, however hard I search I cannot find any contemporaneous games for these retro systems which use a tileset to render (an approximation of) three-dimensional graphics. So is there a technical reason for that?

I am asking because of a game I'm trying to write for the Commodore 64. My choice of platform has meant that the compute budget really is quite miserly, so of course I need to cut down on the amount of time spent pushing pixels to the framebuffer, and tile-based graphics are an obvious solution to that problem on this platform. Also I need to keep in mind the amount of time spent in 3D projection, and I believe this problem can also be solved with tile graphics, since for example a raycaster could cast one ray tile instead of one ray per pixel. But I'm unsure about that.

So the camera in my game is restricted to movement in one plane in the same way that the camera in DOOM is. It pans left and right only, and moves forward and sometimes backward. Plus I know that the walls in my game always are East-West or North-South. No diagonal walls. I think that this will mean that a manageably small number of pre-computed tiles will be enough to show the walls at various angles depending on how the camera is positioned.

---

The nature of this question is such that it could be answered in the following ways:

• It wouldn't work because ...
• You obviously weren't looking hard enough because here's an example of a game that does that. Here's a disassembly or source code so you can figure out how it worked
• It might be possible, but you'd have to watch out for ...

Answer 1

But, however hard I search I cannot find any contemporaneous games for these retro systems which use a tileset to render (an approximation of) three-dimensional graphics. So is there a technical reason for that?

That all depends on your definition of "an approximation of". Games that use pre-rendered sprites were hardly unheard-of in the 16-bit era. You could consider that "an approximation of" 3D graphics.

Would you consider a game like Marble Madness to be "an approximation of" 3D graphics? It doesn't render polygons, but it is polygonal in aesthetics. And it is 3D-ish. What of a game like Captain Skyhawk, which uses a similar polygonal backdrop and is even more 3D-ish?

But a first-person kind of game like what you're trying to describe is a different beast. Those games just use tiles to generate a background that appears polygonal, a static background at that. You want to do real 3D.

The SNES was capable of Doom because the SNES had enough video RAM for the CPU to basically use the tile data as the framebuffer. And it had a CPU fast enough to compute the pixels for that tile framebuffer every frame or so. That is also what the example you gave is doing: the PPU of the Genesis was just being given a bunch of tile bitmaps (generated externally and therefore can be fast), and they formed a single image.

It's just building a framebuffer, chopping it up into tile-sized blocks, and shoving that into a graphics chip designed to render tiles. It's not that impressive, is it? It's just a matter of having enough tile memory to give each location on the screen a separate tile.

Attempts have been made to do Doom on the C64, but they were only successful by giving it a faster CPU. It's simply not feasible to do the kind of thing you're trying. Not generally at any rate.

Answer 2

This is not really an answer to the latter parts of your question but more to address

As we know, tiles can make it quicker to update large portions of the display at once, as compared with a bitmap. To put, say a letter, on the screen, the Commodore 64 typically does two writes (the screencode and the attribute)

What you are effectively describing is a compressed framebuffer where you are directly writing/storing compressed data and letting the display pipeline decompress on the fly.

I would say that such things "still exist" in today's games/hardware, but not perhaps in the form you are expecting.

1. Compressed frame buffers do still exist. Mobile devices certainly do (for example Imagination/PowerVR have PVRIC, and I believe ARM devices have their own scheme) These compression schemes are generally "transparent" to the programmer, but it does mean the GPU and display pipeline does less reading and writing of external memory.
   
   

2. A display decompression system like PCG (Programmable Character Generator) is effectively a precursor to (and effectively a subset of) some texture compression schemes, e.g. such as S3TC/DXT1. In that sense, therefore it still exists, but users don't typically write directly to them, but certainly take advantage of the bandwidth savings.