A New Game Written in D

[ryuukk_]

> I know GCs are a big source of contention, particularly so 
> among game developers, but I have to say I've never really 
> experienced one of the (theoretical) scenarios where a GC ruins 
> a game's performance or something like that, at least not with 
> the D GC. It seems to just be a matter of not doing crazy 
> things (like running heap-based operations every frame) and 
> pre-allocating everything that you can with pools or something 
> similar.

The concept of GC is fine, it exist in both Unreal and Unity

The only difference is their implementation

Both Unreal/Unity doesn't have "much" problems because they use 
some sort of incremental GC, usually multithreaded

The problem of D is it's the worst implementation for games, it 
scans your entire heap, while doing so pauses all the threads

The bigger your heap is (wich games usually have), the longer the 
pause will be


It's not a problem for "some" games, but as 144hz monitors are 
becoming mainstream, the need of games running at 120/144fps is 
becoming crucial

For 120fps, your frame budget is only 8ms, no time for any GC 
pause

Even thought GC's story is better on Unreal/Unity, they still 
struggle, constantly, wich GC issues, a simple google request is 
enough to validate the point)

I used to not care about the GC, until it started to get in my 
way, since then, malloc/free/allocators, and nothing else

Designing an engine this way gives you much more control, GC for 
scripting only in isolated thread!

That's why it is dangerous to tell people to not mind the GC and 
"just program", no, you have to be meticulous about your 
allocation strategy to properly make use of the benefits that a 
GC will give you!

GC is an ice thing, when used properly, depending on its 
implementation!