If you use the type of look-up tables I used in my raycaster, it might just be fast enough to be playable, depending on the resolution you use.RT-55J wrote:Just out of curiosity, what kind of performance could we expect from a software renderer?
If you use the same size of software pixels as my raycaster (8x2 hardware pixels), the screen area the 3D track occupies is 32x48 software pixels (256x96 hardware pixels) large and there are 256 possible angles, you'd need a 48 pixels in a column x 64 angles x 16 fisheye correction angles x 2 axis = 98304-byte look-up table to render the 3D view. Each track would also occupy a lot of space, because they have to be stored uncompressed if we expect to read pixels from them fast enough. Even if an image is as small as 256x256 pixels that's 65KB or PRG-ROM.
The table would tell you where in the track's raw bitmap to fetch the color of each screen pixel, relative to the camera's position. For each pixel, you'd have to perform two additions, read the pixel from the bitmap and write it to the screen. Finally, you'd have to write the 384 tiles to the name table, but you can do it across multiple VBlanks since there is always a hidden name table.
The logic would go something like this:
Code: Select all
for each of the 32 columns: calculate the look-up table pointer based on the absolute and relative angles; jump to one of 4 loops depending on the quadrant of the absolute angle; for each of the 48 pixels: read the horizontal offset from the table; add the offset to the camera's horizontal coordinate; read the vertical offset from the table; add the offset to the camera's vertical coordinate; make a pointer to the track's bitmap using the results; read the pixel from the bitmap and shift it into the tile buffer; next pixel; next column;