Lovely book. Skimming through it. One thing that might help contextualize it is a brief discussion of the how contemporary hardware like the SNES rendered sprites so efficiently compared to the PC hardware at the time. It's not obvious to modern readers why a PC with significantly more powerful compute capabilities would struggle to keep up with significantly slower Nintendo hardware at the time for sprite rendering.
>It's not obvious to modern readers why a PC with significantly more powerful compute capabilities would struggle to keep up with significantly slower Nintendo hardware at the time for sprite rendering.
To put it briefly, 4th generation and earlier games consoles saved on expensive RAM by not having frame buffers [0]. The CPU wrote a description of how to construct the scene using tiles and sprites to a smaller video ram, then dedicated video hardware converted this to the video signal one line at a time. The whole frame gets rendered from scratch every video refresh, so there's no need for tricks like Commander Keen's adaptive tile refresh. Scrolling at 60 fps (or 50 fps for PAL hardware) is as cheap as changing a single value in video memory. It's like the famous "racing the beam" of the Atari 2600, except less flexible and done by dedicated hardware so you don't tie up the CPU.
On the PC, the CPU writes the actual graphics to a frame buffer, then the graphics card outputs the contents of the frame buffer as the video signal. The naive approach to scrolling requires rewriting the entire frame buffer, so tricks to avoid redundant writes are highly beneficial.
[0] Except for the Atari Lynx, which was a portable system with a screen resolution of only 160×102. I can't think of any other exceptions, but maybe there are more.
I get what you're saying, but the comparison to "racing the beam" is maybe a little misleading, because the point is that you aren't "racing" the beam. Rather, the system is operating in perfect lockstep with the beam. From the software perspective, you set the scene up and then sit back while it draws. And then in the abstract and from the hardware's perspective it's not even one line at a time, it's one dot at a time.
>Rather, the system is operating in perfect lockstep with the beam.
That's the same as the Atari 2600. It just occurred to me that the name "racing the beam" is misleading because you can't be too fast either. "Matching the beam" would be a better name. My point is the graphics hardware in both the 2600 and in tile+sprite consoles assembles the graphics just before it's sent to the video output without buffering the whole frame. The main difference is the 2600 graphics hardware is typically reconfigured every line while the later consoles' graphics hardware is typically reconfigured every frame (although re-configuring between lines is usually also possible, and some games left it unchanged on some screen refreshes to save CPU time at the expense of lowering frame rate).
>from the hardware's perspective it's not even one line at a time, it's one dot at a time.
Mostly true, but I tried to make the description generic to as many systems as possible, so "line" is IMO more broadly accurate because a line is composed of dots. The Neo Geo is a tile + sprite system too, and it renders to line buffers.
the Gameboy, not the SNES, but this talk is very very good at going in detail about a bunch of internals. The graphics stuff is 29 minutes in but I love the whole video. Very much a high level guide to building a "retro-y" fantasy console for people into that stuff
"...I discovered Fabien Sanglard’s website and began reading his Game Engine Black Books on Wolfenstein 3D and Doom. Inspired by those works, I wondered whether I could do something similar for Commander Keen: open up the source code, explore the files, and piece together a picture of the overall architecture and the clever tricks used. The style, dimensions, and structure of this book are intentionally similar to Fabien’s Game Engine Black Books, as an homage to those masterpieces. To give it a personal twist, I inverted the title and cover to white."
I suppose there's still Quake 3 Arena and DOOM3 to complete the full "John Carmack" early 90s to early 2000s technical overview series.
Or maybe something with the Sega Saturn. I heard the Sonic X-treme team worked so hard to make a 3d Sonic game for that platform in the mid 90s that multiple team members had to go on medical leave!
How do you feel about this book mirroring your prior art in both format and structure? Were you consulted beforehand?
[EDIT] - I see in the Keen book's source git commit logs that you reviewed and assisted with proof reading beforehand, so may we assume that this is all above board and sanctioned by you?
I think it's a really cool homage, but that the site could be a little clearer that it's not Fabien's work. When I first clicked through and saw a different name, I was hopeful that someone had started a publishing house dedicated to high-quality dissections of classic games.
It appears the author is leveraging Fabien's branding by copying not only the style of post but more importantly the formatting and style of Fabien's books. Even structurally the book appears quite similar.
If you didn't double check the author while skimming this Keen book, you may well be mistaken that it was written by Fabien.
I took a quick skim of the content, it looks great - tempted to purchase a copy to support the author for their efforts (and have it sit on the bookshelf next to two other very similar looking books...) but need to sit on this for a while.
Maybe I'm overthinking this. Would like to hear Fabien's take on the situation.
[EDIT] It looks that the Keen book author copied and pasted direct sections[1] out of Fabien's book's TeX[2].
[EDIT] The git commit history has comments that indicate that Fabien reviewed the book, e.g. "updated all chapters after feedback Fabien" and "Proofread Fabien Sanglard en hardcopy review", so perhaps this is all sanctioned.
I received early draft from bas. While I encouraged him to finish his book, I also told him, in no uncertain terms, that I had released the source code to inspire people and give them a kickstart, but not for them to copy the content.
As months passed, I asked repeatedly to remove whole paragraphs he had copy/pasted as is, and drawings he had also copy/pasted. Later, as A.I became more powerful, I used it to compare Wolfenstein 3D and Keen book and noticed a lot more that was verbatim. At which point I told him I no longer wanted to help him in his project.
It is cool that someone documented Keen thanks to my framework. But I have only myself to blame for opensourcing the code of my books/website and thinking people would use it as intended.
PS: I commented it was a "good idea" to change the cover because originally this was going to be the "Game Engine Black Book: Commander Keen". I did not like that his work could have been mistaken for mine (he also elected to use the same style as my website for his website which only adds to the confusion).
I started building a VR game during COVID and released it 2024. When it released, I was using GPT and Copilot to add a lot of quality-of-life stuff (like visual juice) faster.
Yesterday, I finally got around to setting Opus 4.8 on the codebase. It was able to find and correct numerous subtle performance issues.
Features I could no longer spend time implementing, it could one-shot in roughly 10 minutes (not without issues). I could also fan out agents to work on multiple things at once.
One thing I found is that the knowledge I gained from doing things by hand greatly helped reject bad AI generated ideas. For example, my game is a starfighter flight sim and one idea was to tick AI collision detection checks lower the further AI ships were away from the player, which for a flight simulator leads to a lot of crashing into the terrain. A great idea for an FPS, but a terrible idea for a flight sim where enemy ships are often very close to the terrain.
My takeaway is that we are in a golden era where we currently have projects that are half human coded, where AI can pickup the slack. But soon we will be in the Dark Ages where AI generates all the code, and the end result will be much worse as the devs begin to lose an understanding of what they are creating.
I recently tried to learn gamedev with Claude as a tutor of sorts. It didn't end well. Claude confidently led me off a cliff and I had throw the whole thing in the trash. It seems there's just no shortcut around learning stuff the hard way. When I've got enough reps in to be able to tell smart vs. stupid decisions, I imagine it'll be a lot more useful, but at this point I suspect AI is far from being good enough to get us into your described Dark Ages.
When I was doing my PhD in bio one of my colleagues developed something called CRISPR gene drive, which had the potential of exterminating species wholesale. There was talk of using it to wipe out mosquito populations.
The riskiness of it was quite high though. Wonder if people will consider reviving it in this case.
Unintended consequences of wiping out a species, evolved resistance to the gene drive modifications, accelerated unintended mutation, cross species jumps of the transgene.
The intrinsic limitation of text diffusion is that natural text contains serial dependencies where a word at the beginning of the text strongly influences what comes later, and if there is a long enough dependency chain within a diffusion block, the small number of diffusion steps may not be enough to resolve all dependencies, so that you end up with incoherent output.
This was exactly what I was thinking of. RLVR is the secret sauce behind o3 and its many successors.
Its the secret sauce behind why the current models are so great at coding and soon to be unbeatable at math.
LLMs can pose many questions and if they are easily verifiable, fine tune very heavily. A lot of the world models discussion will inevitable lean into simulations as verification.
I'll admit that I miss having access to the ChatGPT 4.5 "absolutely gigantic model" with enough tuning to make it sane and useful. The RLVR models are superb for actual tasks in those RLVR domains, but that fine tuned view of the world as a verifiable problem to solve makes them feel worse for touchy feely stuff. Even for medical consultation and diagnosis, RLVR model's urge to reach a conclusion often is a liability.
It's RLVR tuned, but not to the ChatGPT level of brain damage, and it's still backed by a fuck off huge pool of model weights - which matters for what you call "touchy feely stuff".
I attended a talk by Brian at Stanford, and I asked why not just use Gibson assembly to stitch together 5 kb synthesized strands from a company like Twist Biosciences.
The answer I got was along the lines that they were simply going to get around to do the actual lab work at some point.
DNA synthesis technology hasn't really been a blocker for generative bio projects except at the full chromosome level.
And I think simply generating a full chromosome and booting it up without doing due diligence is probably a recipe for disaster.
We honestly aren't that far away from AI slop enzymes, AI slop ligases, and eventually AI slop bio weapons...
Imagine if you replaced "games engineering" with "political history" or "nuclear physics"
reply