This is a first attempt to render textured height maps in something close to real time. I guess these would be considered voxels?
I am casting rays from the screen and checking intersect with the floor plane to get an x,z coordinate. Then I load a pixel from the map for the color and a pixel from the map at an offset location to get a height value.
A neat feature is that shadows could be baked into the texture.
Code is ugly, buggy, and poorly optimized...
Issues:
--In order to keep the frame rate up while moving, I had to double pixel size.
--Looking up a pixel on the map is very slow, but I want to be able to handle 512x512 height maps and this is the best way I can think of. (512x512 color map and 512x512 height map)
--tall vertical walls jump in and out of existence, especially when at a distance. Actually, this happens with all pixels. Rounding errors perhaps?
I'm going to look at Zep's Raycast demo and see if there is anything in there that I can borrow.
-ElectricGryphon
Was playing around with it and ever so slightly boosted the performance
Most/all of the performance issues come from get_map_pix and the rectfill
Hi Gamax92,
Thanks for the speed up!
from:
local tile_y = shl(flr(shr(tile_number,4)),3)+y%8
to:
local tile_y = band(shr(tile_number,1),0xfff8)+y%8
What does the binary AND do in this case? It definitely squeezes a little more speed out of things. I guess it combines one of the shift and floor operations?
Right now I am using two get_map_pix commands to find the color and the height of the pixel--I think I can combine these into one (and have the height map for a sprite just 8 pixels offset from the sprite) and shave a little more time. (Also this will make map editing easier and allow for larger spaces.)
The other thing that I am planning to change is the resolution with the rectfills. May just bite the bullet and switch to the 64x64 resolution screen hack.
the band is being used to cut off the last three bits, and the shr(, 1) is still there since the overall bit displacement was 1 to the right
I could see a terminal velocity type game being made with this! I don't think performance is good enough for it though.
Double Pixel size? Why not change the screen mode?
Screen Modes by sta64
For 64x64 resolution:
poke(0x5f2c,4) |
[Please log in to post a comment]