My unfounded hunch for the computing bit is that home computers became more and more commonplace in the home as we approached the 21st century.
A Commodore 64 was a cool gadget, but “the family computer” became a device that commoditized the productivity. The opportunity cost of applying a computer to try something new went to near zero.
It might have been harder for someone to improve the productivity of an old factory in Shreveport, Louisiana with a computer than it was for the upstarts at id to make Doom.
Super Mario 64 is a video game that’s had a lot of rereleases, both official and unofficial. I sometimes wonder if the most people who have experienced it did in a way that wasn’t like the original Nintendo 64. The Switch version sold almost as many copies. As a kid, I beat it with arrow keys on an emulator in 2001.
When I read the responses to this document, I wonder if Dragon Ball is the same, where the collective nostalgia is actually quite diverse.
I think the source code in the GitHub repo generates the ROM in the corresponding screenshots, but it seems quite barebones.
It feels very much like it’s cobbled together from the libdragon examples directory. Or, they use hardware acceleration for the 2D sprites, but then write fixed-width text to the frambuffer with software rendering.
Partially correct. The value is not the game interface right now. Its proof you can do actual inference on an LLM the surprise I am developing is a bit bigger than this, just have to get the llm outputs right first!
You’re right that the graphics layer is mostly 2D right now. Sprites are hardware-accelerated where it makes sense, and text is written directly to the framebuffer. The UI is intentionally minimal.
The point of this ROM wasn’t the game interface — it was proving real LLM inference running on-device on the N64’s R4300i (93 MHz MIPS, 4MB RDRAM).
Since the original screenshots, we’ve added:
• Direct keyboard input
• Real-time chat loop with the model
• Frame-synchronous generation (1–3 tokens per frame @ 60 FPS)
So it’s now interactive, not just a demo render.
The current focus is correctness and stability of inference. The graphics layer can evolve later.
Next step is exposing a lightweight SDK layer so N64 devs can hook model calls into 3D scenes or gameplay logic — essentially treating the LLM as a callable subsystem rather than a UI gimmick.
The value isn’t the menu.
It’s that inference is happening on 1996 silicon.
Happy to answer specifics about the pipeline if you’re interested.
Simultaneous turn based top down car combat where you design the cars first. Inspired by Car Wars, but taking advantage of computers, so spline based path planing and much more complicated way of calculating armor penetration and damage.
My first job out of school was on one of the HD expansions at SkyBox Labs. It was mostly grunt feature work and desync fixes, but I remember that some of the handcoded ASM from the legacy pathfinding had been one-to-one translated to C++.
I always wondered if that contributed to the pathfinding regressions that were talked about online. Or, you learn about compiler-induced accidental UB in school, and part of me wondered if something was happening there.
If you’re being objective about a programming language, its strengths and weaknesses are always going to a reflection of the game you’re trying to make. Python’s ecosystem will get you very far making web services, but less so with cert on consoles.
C# and GDScript are no different. They both have made design decisions for particular reasons.
You’re a skilled developer in real languages, so I’d encourage you to explore why other developers might prefer a DSL for their needs!
I tried the 7DFPS Game Jam this month, trying to learn a little more 3D modelling, as well as Godot. It was my first time using the engine to produce a HTML5 build.
Within the scope of a game’s production, the programmer time spent dogfooding the new audio format can be used towards something else that improves the value of the end product.
The uncompressed audio for latency-sensitive one-shots usually isn’t taking up the bulk of memory either.
> programmer time spent dogfooding the new audio format can be used towards something else that improves the value of the end product
Like exploring the 'widely accepted industry practices' and writing code to duplicate the assets, then writing the code to actually measure what it did what the 'industry practices' advertised and then ripping this out, right?
And please note what you missed the 'if it really bothers you'.
The last studio I worked at where the Steam Deck came up, the rendering lead muttered “ew, no! we don’t have time to figure that out!” and that was the end of the conversation.
A week after launch, the Proton devs pushed a hotfix and the binary’s been compatible with Linux ever since.
A Commodore 64 was a cool gadget, but “the family computer” became a device that commoditized the productivity. The opportunity cost of applying a computer to try something new went to near zero.
It might have been harder for someone to improve the productivity of an old factory in Shreveport, Louisiana with a computer than it was for the upstarts at id to make Doom.
reply