Reviving YAGE

Benjamin Thaut code at benjamin-thaut.de
Wed Feb 5 22:30:04 PST 2014


Am 05.02.2014 23:39, schrieb Martin Cejp:
> On Wednesday, 5 February 2014 at 21:37:22 UTC, Benjamin Thaut wrote:
>> Am 05.02.2014 22:21, schrieb Ryan Voots:
>>>
>>> At the moment I don't think it really does deal with GC pause times and
>>> it's one of the things that will need to be dealt with.  I believe it's
>>> possible (I am still learning much of D) to tell it to not do any GC
>>> during critical paths which should help keeping it from mangling things
>>> mid-frame.  There also appears to be some threading support already in
>>> the engine to do rendering on a seperate thread which should help out at
>>> keeping frame rates up if the GC can be kept to a minimum there.
>>>
>>> In any case I'm not currently aiming for getting the engine capable of
>>> 300fps with very low latency as it isn't necessary for what I'm after
>>> though once it's working I certainly won't turn down someone who wants
>>> to get it that far.
>>>
>>> What I'm hoping to get out of this is more a basic framework for
>>> relative ease for making games more like say the engine Unity provides
>>> or some of the other things out there.
>>
>> If you didn't deal with GC pause times, you will have quite some fun
>> with it. I wrote a small game engine in D, and I ended up running the
>> garbage collector every frame to get stable framerates. Not doing it
>> resultet in 3-10 second pauses during gameplay because of GC collection.
>>
>> http://www.youtube.com/watch?v=mR2EQy3RRyM
>>
>> Because the GC used up to 8 milliseconds every frame (which is 50% for
>> a 60 FPS game), I finally removed the GC from druntime and I'm using a
>> GC free version of D since then. This however comes with maintaining a
>> custom version of druntime and phobos (stripped down to about 10% of
>> the modules) and writing my own standard library.
>>
>> You can read more about the GC issues here:
>> http://3d.benjamin-thaut.de/?p=20
>>
>> Kind Regards
>> Benjamin Thaut
>
> Those numbers are pretty scary. How many objects are you allocating and
> trashing each frame?

Well, consciously allocating, almost none, only if a new object (like a 
particle effect) is spawned. But after moving to the no GC version I 
discovered how many hidden allocations there are. Especially array 
literals, lambdas, and array concardinationd allocate like crazy. Also 
phobos functions (format etc). So there where quite many allocations per 
frame. The allocations per frame don't really matter though, because the 
runtime of a Mark & Sweep collector does not depend on the amount of 
Garbage. A Mark & Sweep has to look at all alive objects, so that 
defines the runtime. And the Problem with a game is, you usually end up 
with a lot of alive objects and almost nothing of that is garbage. So 
the GC collect times are constantly high.

Kind Regards
Benjamin Thaut


More information about the Digitalmars-d mailing list