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
