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).
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.
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?
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?
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.
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".
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!
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.
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
This is more interesting since it's actually 3D
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).
Yes, it reminds me a lot of the ports between 8-bit computers in the 80s, and also console ports pre-Playstation.
Agreed - I expected someone trying to render a simple object or scene and was pleasantly surprised.
Highly relevant:
Surface-Stable Fractal Dithering
https://runevision.com/tech/dither3d/
https://www.youtube.com/watch?v=HPqGaIMVuLs
Way, way too slow for Playdate though. I tried implementing it, including lots of simplifications, and it is still not really practical: https://aras-p.info/blog/2025/02/09/Surface-Stable-Fractal-D...
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!
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?
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...
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...
LCD 1 (2022) is an ASCII art project on the same display (by Sharp) of the PlayDate.
https://lcd.ertdfgcvb.xyz
Amazing. I never get over the 2 bit colour illusion of scale.
Does the upscaling from 200x120 happen pre or post dithering?
If my eyes don't deceive me, the upscaling is happening post-dithering, which I think is a shame.
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".
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! :)
+1 for TrenchBroom, it’s amazing software.
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!
[flagged]
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.