dougeff wrote:
Kind of what I had in mind, but maybe 90°, 67°, 45°, 22°, 0°. And much less detail. No textures.
But you need some sort of drawing on the floor to separate the road from the rest of the ground, and if you're looking up flat colors from a map you may just as well look up textures instead... there's no increase in processing time.
Just to make it clear, I'm not talking about pre-rendering or anything like that. The look-up tables I mentioned are X and Y offsets, relative to the position of the player, indicating where in a 2D map each pixel in the screen should come from. For each pixel, you take the player's coordinates, add the offsets, and then look for the pixel at the resulting coordinates in the 2D map. The map can be encoded like in a platformer or an RPG, using metatiles. Since you're already looking up the pixel color, it doesn't matter if the graphics are flat or textured.
Here's an example: Imagine a craptastic resolution of 10x5 pixels for the floor. Each line in the look-up table will have 5 pairs of coordinates (red dots) relative to the player (black dot), and you'll have to process 10 lines in order to cover the entire FOV:
Attachment:
floor-casting-1.png [ 6.88 KiB | Viewed 2977 times ]
Attachment:
floor-casting-2.png [ 9.56 KiB | Viewed 2977 times ]
These are 2 different angles. You'll need quite a few lines so that rotations feel smooth enough. The good news is that you only need to store values for 90 degrees, since the rest can be calculated by inverting signs.
After you calculate the final coordinates, you can just check in the map what pixels are under them, and use those colors to draw the perspective view:
Attachment:
floor-casting-3.png [ 17.29 KiB | Viewed 2977 times ]
Let's talk real numbers now. In my crappy low resolution raycaster I had 42 angles in 90 degrees, so I would suggest at least twice that for a decent 3D road, and a resolution of at least 64x40. So, 84 lines, each with 40 pairs of 16-bit coordinates, that's 13,440 bytes of ROM for the look-up table, not so bad. Now let's look at the CPU time: at 64x40 pixels, we have a total of 2560 pixels for which we need to look up colors. Each pixel needs 2 16-bit additions, each looking something like this:
Code:
clc ;2
lda (Table), y ;7
adc PlayerX+0 ;10
sta ColorX+0 ;13
iny ;15
lda (Table), y ;20
adc PlayerX+1 ;23
sta ColorX+1 ;26 cycles
26 * 2 * 2560 = 133120 cycles. But you still need to look the color up in the map, and buffer it in a way that can be written to the name tables later, which could easily double that time. That adds up to like, 10 frames of processing, so the game would run at 6fps. Not very exciting, IMO. I'm interested in hearing about possible optimizations, if anyone has any.