A #pico-8 homage to the groundbreaking 1993 PC Intro "Mars" by Tim Clarke, in 972 bytes of compressed lua code. Produced for the 2024 #pico1k jam.
Use the left and arrow keys to move sideways along the landscape, and up and down keys to move forward and backwards, respectively.
I was hoping to use SSPR to accelerate this significantly, alas the smoothness of the shading is seriously compromised without sub-texel precision. The PSET way was the only I found to preserve some of the looks of the original material. This came at the cost of performing very few samples, and severely limiting the near plane, thus loosing the ability to perform traversals close to the ground.
Anyone interested in voxel heightmaps should definitely check this excellent cart by @dhostin, with some stellar assists by @freds72. Also this article from Alex Champandard in flipcode from where I believe I learned about this technique originally (or perhaps some article in PCGPE prior, I cannot recall).
remarks:
- neat
- max(0,c) = max(c)
- sqrt(max(c)) = sqrt(c)
- flr: who use that vs \?
- sspr can work - need to adjust sub-pixel shift (same as regular texturing), something like:
sspr(source texel: (y%1)*dy) - related: why flooring k1?
Firstly, let me take a moment to acknowledge the privilege of taking part in the PICO-8 community. Just the day after making a submission, having one of the leading minds in the field review your code and give you advice. Nothing beats this.
Now, in reply to @freds72 kind remarks:
- Much appreciated, especially coming from you!
- replaced max(0, c) with max(c), very useful contraction
- removed the guard for negative number in sqrt, pico-8.fandom needs updating
- who uses flr instead of \? dinosaurs like me! some more bytes saved
- sspr can indeed use subtexel precision. This was catastrophic forgetting on my behalf. I had used this in raycasting, but years after I hallucinated that it needed to use integers for both source and target coordinates
- I was clamping k1 because I was using it in my failed sspr tests (which I was testing on different vertical scans against manual interpolation), it is not only unnecessary but also removes precision in the interpolated shading
I have produced two carts to compare the performance of the sspr variant versus interpolated spans, the latter does produce a significant improvement (brings the framerate above 10fps), but it is still not as smooth.
[Please log in to post a comment]
