Reviving YAGE

[Martin Cejp]

On Thursday, 6 February 2014 at 06:30:04 UTC, Benjamin Thaut 
wrote:
> 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

Looks to me like all of those could be worked around. Surely 
wouldn't make the code easier to read, but it shouldn't be *that* 
difficult. Don't append to arrays (use own pre-allocated vector 
if needed), allocate particle structs in bulk with plain malloc, 
no array literals in the hot path etc. No GC allocations = no GC 
runs