I don't understand why they're calling out the FPS of an empty scene as a useful number compared to Unity though. Ignoring that this engine will have a fraction of the features of Unity (the likely reason for the FPS number in the first place), it's just a useless benchmark because it's an empty scene. `while (true) {}` will get you the same thing.

I'd wish they'd highlight how the engine helps you make a game rather than arbitrary performance numbers on microbenchmarks that don't generalize to a real game project. You can absolutely be faster than Unity, but "9 times faster than Unity out of the box" is not a number people should take seriously without the context of where the number comes from.

I wish them well though. I'm always interested to see more work in implementing engines in GC languages. I'm personally quite interested to see what can be done in modern GC languages like Go or (modern) C# which provide lots of tools to limit GC pressure. Being able to write C-like code where needed in an otherwise managed runtime is a really powerful tool that can provide a best-of-both-worlds environment.

When an engine becomes useful is when it has to make a game. All your abstractions tend to get rearranged and hard decisions are made.

https://unity.com/ leads with demos.

https://kaijuengine.org/ leads with a block of text claiming it renders cubes faster than Unity.

I wish Go didn't have this performance bottleneck because I really like the language and it would be a great middle ground for indie like games that don't want to follow the big engines route but sadly any kind of request of a faster path to call cgo was ignored by the Go team as games is not really something they are interested in.

Still best of luck to the guy but eventually he'll hit a wall and all the claims about performance will look funny.

What is interesting, though, is that engines like this often reveal how much overhead comes from tooling, scene graph complexity, editor integrations, GC pressure, etc. Sometimes a very lean engine feels “faster” simply because it avoids all the layers that a mature engine needs to support large teams.

I’d love to see a demo that stresses real systems — entity updates, materials, batching, physics, etc. That would say far more about the architecture than raw FPS of drawing nothing.

Are there a lot of Unity/Godot devs unaware that their engines are using GC? I would assume they'd have accepted the cost of GC already.

Unreal devs I can understand having an issue with it though.

Maybe TinyGo can save their ass here?

Historically Go was viewed as not the best choice for game Dev because it's GC process was known to cause periodic blips of load, but I wonder now how smooth it is now. I believe one can also plug in arena managed memory and alternatives of that I'll.

If the author reading: I am curious to see an worked out example where writing the assembly code was necessary.

On Windows this only has a resolution of ~0.5ms (down from ~15.6ms when this frame limiting code was written). It also is not synchronized to when frames need to be submitted which means that depending on when the timer is created it can result in the game having stutter.

With such an outrageous and unfounded statement, I'm just going to assume the project isn't worth taking seriously.

Make a real game first, and then we'll talk.

10/10