A New Game Written in D

[Kenny Shields]

On Wednesday, 18 May 2022 at 14:40:59 UTC, ryuukk_ wrote:

> 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!

Thanks for the insight here, very informative. I think the hybrid 
approach works fairly well for my engine's use case, though I get 
what you are saying about the heap size and all that, I suppose 
some games may not be able to avoid that issue without taking the 
manual approach.

Also, I know that D has some sort of interface for allowing 
custom GC implementations -- has anyone ever made a functional 
alternative? Something that takes the incremental approach that 
you mentioned as opposed to the pause and scan method?