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
