Show HN: demake – one source project compiles to any retro game console ROM (geosona.com)
This started life as a graphics tool for a specific problem: gen AI can make retro-styled sprites but can't follow exact hardware constraints of pixels and colors.
While building this I liked the idea that I can fan-out to any retro videogame console or handheld's specifications.
I then devised my own declarative language - Demotic - to express the game you want to build as concisely and naturally as possible without implementation detail. To work on different machines, you use relative units, like vw, vh, vmin, vmax.
It has a web UI, CLI and NPM package. Still a work in progress.
6 comments of 8
[ 0.26 ms ] story [ 14.2 ms ] threadAre there any device capability guards, so more capable systems within a tier (like SNES vs NES) could attempt more complex graphics, sounds or interactions? What works on the Game Boy is different enough from what's possible on the SNES that you may want some way to express that. Or to make it dynamic, like "make the number of enemies the number of supported sprites - 2"
And why does it play top to bottom when the 'net' suggests it should be side to side?
https://yogthos.net/posts/2025-12-11-edge-aware-pixelation.h...
More broadly I often find pixel art that has been upscaled and I'm wondering if anyone knows a good way to convert that back into the original?
In theory you just need to sample the middle of each blob, but I haven't found traditional image editors to be very helpful in this process.
There's some Common Lisp package to code for the web:
https://github.com/rabbibotton/clog
No AI gen would be needed if the game can be structured enough a la GB Studio.