Comment by bobajeff
19 hours ago
About garbage collection:
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.
GDScript in Godot doesn't use GC, it uses reference counting and doesn't "stop the world".
Other languages that bind into the engine do this too, (C++, SwiftGodot, Rust-Godot)
C# obviously does, Miguel de Icaza actually started SwiftGodot because he (ironically) ended up hating GC pauses after promoting C# for so long
Go does surprisingly well at keeping GC freezes to a minimal in a way that you're unlikely to notice... C# has gotten a lot better since the core split as well. That said, there's a lot that comes down to how a developer creates a game.
I was added late to a project working on a training simulation engine, similar to games, where each avatar in the game was a separate thread... man, the GC pauses on the server would sometimes freeze for literally 10-15s, and it was not good at all. I refactored it to use an event-loop model and only 2 other threads, which ran much better overall. Even though it wasn't strictly a game itself, the techniques still matter. Funny how running through a list of a few hundred things is significantly better than a few hundred threads each with their own timers, etc.
> Funny how running through a list of a few hundred things is significantly better than a few hundred threads each with their own timers, etc.
State machines are not in fashion. Exposed event loops are not in fashion. Most frameworks do their damnedest to hide those components.
As for GC freezes, if you're doing a game like project you can always just allocate a few huge arrays at startup and reuse those with no deallocation/allocation in most garbage collected environments.
> C# has gotten a lot better since the core split as well.
It has improved but the majority of games using C# are using Unity which does not use .NET (Core). It uses Mono or IL2CPP specifically with the Boehm GC so it performs significantly worse than .NET and even standalone Mono (SGen GC).
1 reply →
Reference counting is a GC algorithm from CS point of view, as looking into any worthwhile reference will show.
It's not what people mean when they say GC though, especially in reference to games, where you care about your peak frame time more than about your average frame time.
5 replies →
I haven't dug deep enough into C# to say this with certainty, but I believe later C# versions allows you to do enough manual allocation to "almost" get around the garbage collector. As well as new calls to try and nudge the GC away from hot paths.
You need to be very disciplined to pull this off, though. LINQ is basically off limits, for example. And of course, Godot's C# is likely much older than these modern techniques to begin with.
Godot's C# is fairly recent, C#12/.NET 8.
2 replies →
Unreal devs have Unreal C++ dialect with GC, Blueprints and soon Verve to worry about.
The times of pure manual memory management game engines, across all layers of what requires to draw a frame are long gone.
Naturally someone is going to point out some game engine using compiled C dynamic libraries for scripting, those are the exception.
>The times of pure manual memory management game engines, across all layers of what requires to draw a frame are long gone.
That's what makes me curious about Rust engines like Bevy. Could is truly pull it off and bring back that kind of thought to game development? It's not "pure manual memory management", but the mindset of Rust requires that kind of thinking.
It will definitely be niche for times to come, since most (non-AAA) games simply aren't going to worry about performance. But it might carve a solid community for those concerned with optimization.
Thing is, FPS don't make fun games, what makes games fun is a great design, delivered in a way that overall performance doesn't hinder the experience.
That is why games like Minecraft, Roblox, Celeste, Balantro make it big. None of them would have happened if the creators followed the advice 100% C coding (or C++ for that matter) was the only way, and yet their design is what made them shine.
1 reply →
Issue isn't about game devs it's about non-game devs backseat programming.
If you spend a week in these engines you're well aware of the garbage collector.
In my experience, when using Unity, I became acutely aware of creating garbage and how to avoid it. I used to see a lot of object pooling which is basically a makeshift arena allocator.
Can you explain? AFAIK Godot uses C++ under the hood which does not have garbage collection. Other languages such as C# and GDScript use bindings.
Most people using Godot will be using GDScript or C# to make their games.
Funnily enough whilst trying to Google gdscript and godot, I found this post I wrote in 2018 (subcomments mention gdscript and gc).
https://news.ycombinator.com/item?id=16673751