Building a Tiny 3D Renderer for a Tiny Handheld

For anyone who enjoys this sort of thing, I found this postmortem of an Alone in the Dark clone for PICO-8 highly informative:

https://www.lexaloffle.com/bbs/?tid=3804

What an excellent example of designing for the medium instead of trying to make the medium do something it's not good at! Your whole approach shows a real love, like a delicate respectfulness, that I think characterises early games and is less apparent as the systems get better (though I am sure it is still there).

Highly relevant:

Surface-Stable Fractal Dithering

https://runevision.com/tech/dither3d/

https://www.youtube.com/watch?v=HPqGaIMVuLs

I love this post because it goes well beyond "can I render 3d graphics on this device" and into "how can i play with the combo of art and rendering tech to get a nice looking scene on this device.

Very cool, thanks for sharing!

This is breathtaking. I did something similar[1] porting a 3D dice roller I wrote to a $60 GBA clone, and I _thought_ that was hardcore already. This is next level.

[1]: https://blog.myli.page/rolling-dice-on-a-60-handheld-08be278...

Remind me of a similar quest of mine from... 15 years ago or so. Porting Quake on a GP2X handheld with no GPU, not even an FPU, run by an ARMv4. I could not compress the textures enough at the time so you could play only for a few seconds before the memory became too fragmented and the game stopped. But I managed to port a few other games. The PlayDate is a supoercomputer compared to an ARMv4 from 15years ago, but that antique GP2X was at least capable of true-color :). Should still have the code somewhere on github, but that's probably completely unusable on any hardware available in 2026. Maybe the "opengl" compatibility layer could still be useful though?

LCD 1 (2022) is an ASCII art project on the same display (by Sharp) of the PlayDate.

https://lcd.ertdfgcvb.xyz

They mentioned that they wrote their own assembly functions for some floating point routines, like sqrtf. Is the ARM floating point unit fast enough that the quake fast inverse square root [1] isn't required?

[1] http://betterexplained.com/articles/understanding-quakes-fas...

Amazing. I never get over the 2 bit colour illusion of scale.

Does the upscaling from 200x120 happen pre or post dithering?

Given the 168MHz ARM, the real innovation here is the way stable dithering and a cell shading look was used to make the graphics good looking. Very well done!

Actually done a good job - talks about dithering, perspective correct mapping and the artifacts seen in the PS1 era etc. Pretty good start.

Add more lighting and shadows to the game before that dithering pass and then see how far you can push this, and write about it. Cheers! :)

Thanks for sharing both an amazing topic - engineering with significant constraints, a great medium - handheld game devices, as well as some wisdom - If you want to make actual progress, try to aim for "good enough".

+1 for TrenchBroom, it’s amazing software.

Looks nice for such wimpy hardware.

But using 16-bit Z-buffer for 1-bit display seems to be an overkill. Sorting polygons works mostly fine if done right, especially if BSP tree is already used.