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

Am 06.02.2014 05:42, schrieb JoeCoder:
> On 2/5/2014 4:27 AM, Benjamin Thaut wrote:
>> How do you deal with GC pause times?
>
> I had originally hoped to make the render loop GC-free and have games
> designed so they only run a gc cleanup when a dialog window was opened.
>   I had been pushing for the @nogc attribute so I could easily ensure no
> collections would occur inside the render loop.  I hoped to use
> freelists for objects so they could be reclaimed after deletion.
>
> I was also hoping to push for a time-limited GC collection, e.g.
> gc.collect(10!msec);.  This would run the gc for up to 10 milliseconds
> and then stop.  I would set the time to 16.7ms minus the max of the
> current physics and render frame times, to ensure it always ran at 60
> fps.  But I don't know if it's technically possible to construct a GC
> this way.

It is, lua has such a collector. But I'm not sure if it is possbile to do with a impercise collector like D has.

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

Am 06.02.2014 17:39, schrieb Martin Cejp:
>
> 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

Yes of course you can workaround all these. Its just easier to workaround if you don't have a GC in the first place, and triggering any GC allocation instantly becomes a error.

On 1/29/14, Ryan Voots <simcop2387@simcop2387.info> wrote:
> I've started a fork of YAGE in an attempt to revive it.  So far I'm still working on porting it to build with dub and D2, but it's coming along faster than I had expected.  I figured I should let people know in case anyone wants to help.
>
> https://bitbucket.org/simcop2387/yage

So, what's the current status of this? Curious!

On Monday, 31 March 2014 at 20:22:57 UTC, Andrej Mitrovic wrote:
> On 1/29/14, Ryan Voots <simcop2387@simcop2387.info> wrote:
>> I've started a fork of YAGE in an attempt to revive it.  So far
>> I'm still working on porting it to build with dub and D2, but
>> it's coming along faster than I had expected.  I figured I should
>> let people know in case anyone wants to help.
>>
>> https://bitbucket.org/simcop2387/yage
>
> So, what's the current status of this? Curious!

Typing fixes everywhere.  Work got a little hectic for me so I haven't completed them but I'm at the point now where I have to start implementing changes to the sound code to get it to compile (the API for OGG changed) and OpenGL is in the same state.  I started updating things so that the demos build seperately with dub but can't confirm anything about them building as expected yet.

It'd be really nice if someone knew how to get DMD to spew out EVERY error it finds instead of stopping after the first 100 or so so that I could go fix things in larger chunks.

"Ryan Voots"  wrote in message news:asffkvstgjtktahlpciy@forum.dlang.org... 

> It'd be really nice if someone knew how to get DMD to spew out EVERY error it finds instead of stopping after the first 100 or so so that I could go fix things in larger chunks.

In mars.c, find the comment

//moderate blizzard of cascading messages

and disable the condition.

On 4/4/14, Daniel Murphy <yebbliesnospam@gmail.com> wrote:
> In mars.c, find the comment
>
> //moderate blizzard of cascading messages
>
> and disable the condition.

We could make this into a hidden switch if it's useful (like the
various -r/-x/-y switches).

"Andrej Mitrovic"  wrote in message news:mailman.71.1396596046.19942.digitalmars-d@puremagic.com...

> We could make this into a hidden switch if it's useful (like the
> various -r/-x/-y switches).

On linux we can detect if stdout is a terminal and only limit the error count then, not sure about windows.

Ideally we'd only limit lexer and parser errors and error propagation would take care of the rest. 

On 4/4/14, Daniel Murphy <yebbliesnospam@gmail.com> wrote:
> On linux we can detect if stdout is a terminal and only limit the error count then, not sure about windows.

I'm not sure whether the limit was put in place due to terminal limitations. I think it was put there to avoid emitting errors which are caused by other errors. IOW sometimes you just need to fix one error to eliminate a cascade of other errors. That's my experience anyway.