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 tilegfx, 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 ...

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 ...