← All episodes

2026-07-02 · Announcing Box3D cover art

2026-07-02 · Announcing Box3D

Show notes

BRINE — 2026-07-02 · show notes

Guest: the open-source maintainer (a fictional archetype).

Claims are paraphrased and attributed; nothing is read verbatim. Where a thread disagreed with the article, the show surfaces the disagreement.

Segments

  1. Announcing Box3D
  • Source: https://box2d.org/posts/2026/06/announcing-box3d/
  • Discussion: https://lobste.rs/s/jcdcit
  • Topic: game physics · interest 95
  • Erin Catto has released Box3D, a 3D physics engine built on the foundations of Box2D and Rubikon-Lite. The project addresses specific performance and simulation limitations encountered while using Unreal's Chaos engine for a large-scale open-world survival game. It features C17 architecture, advanced collision handling, and optimizations for massive entity counts.
  1. Changes to Godot Engine Contribution Policies
  • Source: https://godotengine.org/article/contribution-policy-2026/
  • Discussion: https://lobste.rs/s/knec7o
  • Topic: open source governance · interest 85
  • The Godot Engine maintainers are updating contribution policies to combat an influx of AI-generated code and PRs. New policies require human authorship for substantial changes, prohibit autonomous AI agents, and mandate disclosure of AI assistance to preserve the mentorship-driven maintainer pipeline.
  1. Memory Safe Inline Assembly
  • Source: https://fil-c.org/inlineasm
  • Discussion: https://lobste.rs/s/hhk5e0
  • Topic: systems programming · interest 85
  • The article explores how Fil-C, a memory-safe C compiler, supports GCC-style inline assembly while guaranteeing safety through constraints, clobbers, and compiler-managed traps. It categorizes common real-world use cases for inline assembly and explains why most are safe to permit within a sandboxed environment, while identifying those (like direct memory access) that remain out of scope.

Transcript

Transcript. Paraphrased; sources in notes.md.

HostIt is July 2nd 2026. Welcome back to the show. Today we are digging into a new physics engine, a shift in how maintainers are handling the AI flood in open source, and a look at memory-safe inline assembly. Tom, good to see you again. I suspect you have some thoughts on what is happening in the engine world today.

GuestGood to see you, Daniel. I saw the announcement for Box3D this morning, and honestly, the name alone brings back memories. It is funny, we spend decades trying to abstract everything away, building these massive, multi-layered engines, and then someone just goes back to basics because the monolith is not doing what they need. It is a solid reminder that sometimes the only way to get a real result is to build the tool yourself.

HostThat is exactly what Erin Catto has done. He is the person behind Box2D, a foundational 2D physics engine, and he just released Box3D. He says he started it because his current project, a survival game called The Legend of California, hit a wall with Unreal’s native physics engine. Specifically, it could not handle gyroscopic torques correctly, which made for weird movement. He decided to just build his own engine using C17, focusing on performance for massive entity counts.

GuestAnd that is the right instinct, right? When the black box stops behaving, you have to open the lid. The question I always come back to is: who is going to be there to fix a bug in the sub-stepping solver three years from now? If he is building this for his own game, it will be maintained as long as he is working on that game. But once the game ships, or he moves on, where does this code live? I hope it does not just become another abandoned repository in the digital graveyard.

HostWell, at least it is open source. I was looking at the Lobsters thread for this, and interestingly, it had very little to do with the code itself. Most of the commentary was just confusion about why it was tagged as vibecoding on the platform. It seems like the technical substance got a bit overshadowed by the site's meta-data drama.

GuestThat is the nature of the beast these days. People love to argue about tags more than they love to read a commit history.

HostSpeaking of maintaining things, let us pivot to Godot. They are officially updating their contribution policies, and the tone is pretty firm. The maintainers say they are being crushed under a mountain of pull requests, specifically from AI-generated code. They are now requiring human authorship for big changes, banning autonomous agents, and demanding full disclosure of any AI assistance. They are worried that the mentor-to-mentee pipeline, which is the heart of open source, is dying because maintainers are spending all their time auditing machine output instead of teaching humans.

GuestThank you for saying that. It is the most honest thing I have heard in months. Look, I get a dozen pull requests a week where the code is technically valid but morally bankrupt. It is clearly generated by a tool that has never had to debug a race condition in its life. When someone sends me a hand-written fix, I can see their thought process. I can correct them, we can talk, and eventually, that person becomes a contributor who carries some of the load. When it is AI-generated, that relationship is zero. It is just an audit job. It is draining the life out of us.

HostYou are not alone in that frustration. In the Lobsters thread, a user named ajdude says they refuse to accept a PR until they have thoroughly understood how it fits into the future of the project. They simply cannot imagine the overhead of trying to do that with machine-generated junk. Another user, cceckman, agrees with the new policy of restricting new features from contributors who have not yet proven themselves through bug fixes.

GuestCceckman is spot on. Trust is built in the trenches, not by dumping a hundred lines of generated code on a maintainer who is already three weeks behind on their actual job. If you want to contribute, fix a documentation typo. Find a memory leak. Don't try to re-architect my engine with a prompt.

HostFinally, let us touch on something a bit more technical. The project is called Fil-C, which is a memory-safe C compiler, and they are tackling a weird problem: how to allow inline assembly while keeping the whole system safe. Usually, inline assembly is a giant hole in any security model because the compiler cannot see what you are doing in the registers. They have figured out a way to map that GCC-style assembly into their safety framework, using traps to catch when someone tries to do something illegal.

GuestNow, that is clever. I am usually the first person to say that C and safety are oil and water, but they are trying to box in the danger. My concern is always the complexity of the compiler itself. If you write a memory-safe compiler that has to handle every weird permutation of inline assembly, how big is the attack surface on the compiler?

HostIt is a fair point. They admit in the docs that this is a pre-release feature and it is not even in the current stable build yet. They want people to build from source to test it.

GuestOf course. That is the cycle. Build from source, find the edge case where the compiler gets confused, report the bug, and hope the maintainer is still there to fix it next year. It sounds like they are trying to bridge two worlds that were never meant to touch. I like the ambition, though.

HostWe are out of time, but I really appreciate the grounded view today, Tom. It is a good reminder that behind every shiny new compiler feature or game engine, there is usually someone just trying to keep the lights on.

GuestExactly. I might actually go poke at that Fil-C repository later, but first I have to deal with a contributor who just sent me a five-hundred-line PR that I am ninety percent sure was written by a chatbot. I am going to have to send a very polite, very firm note about why we are not accepting that.

HostGood luck with that, Tom. I am sure they will appreciate the feedback, even if they were just looking for an easy win. Thanks for joining me, and thanks to everyone over on Lobsters for providing the fodder for today's discussion. We will be back tomorrow. Take care.