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.
I ask this as someone who has no love or support for the Liberals.
reply