On 1/29/2014 1:07 PM, Ryan Voots 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

As the original author of Yage, you have my blessing.  I always wanted to return to it but never had the time.

On 1/29/2014 4:05 PM, Andrej Mitrovic wrote:
>
> Most of the links on the yage homepage seem to be dead. But I'm
> wondering whether any games were made that used Yage?
>

None worth mentioning.  It had too many missing features and I never got it to a complete-enough state.

On 1/29/2014 3:27 PM, Ryan Voots wrote:
> On Wednesday, 29 January 2014 at 18:15:57 UTC, Andrej Mitrovic wrote:
>> On 1/29/14, Ryan Voots <simcop2387@simcop2387.info> wrote:
>>> but it's coming along faster than I had expected.
>>
>> Is it already buildable? Any samples work? Nice that you're working on
>> it.
>
> Not buildable yet, but i've managed to get it started building in dub
> and resolved almost all of the dependencies with it.  The only one it's
> missing is the bindings for GLU directly which i'll likely end up
> writing out of the engine once it starts compiling and then breaking
> during linking from unresolved symbols and such.
>
> Most of the APIs it used have changed in the 2 years or so since it was
> last really updated so there's quite a bit of work ahead, and I plan on
> getting it to GL3+ once it's building and the demos run.  The fun part
> will be to get it to be idiomatic D2 once it's building and working, I
> imagine that will be a nearly never-ending battle unless someone just
> rewrites large parts of it (this might end up happening if I get to it).
>
> It's definitely got enough of the boilerplate stuff for building a game
> that doing this port should certainly help me with my project so I
> figured I'll let it help other's too.
>
> That said I've made some good progess these past two days on getting it
> to build at least so it should hopefully not be much longer (hoping i'll
> have it building but not running properly in a week or so).

I had planned to remove the dependencies on GLU and port to GL3 as well.  You might look into ASSIMP for importing assets and model files. Skeletal animation is broke because I never could get the collada skeleton to lineup with the rest of the model.  I was missing a matrix transform somewhere.

On Thursday, 30 January 2014 at 20:17:54 UTC, JoeCoder wrote:
> On 1/29/2014 4:05 PM, Andrej Mitrovic wrote:
>>
>> Most of the links on the yage homepage seem to be dead. But I'm
>> wondering whether any games were made that used Yage?
>>
>
> None worth mentioning.  It had too many missing features and I never got it to a complete-enough state.

Even saying that it still appears to be the most complete framework written in D.

> I had planned to remove the dependencies on GLU and port to GL3 as well. You might look into ASSIMP for importing assets and model files. Skeletal animation is broke because I never could get the collada skeleton to lineup with the rest of the model.  I was missing a matrix transform somewhere.

Good to know about the skeletal animation being broken, that'll help to when testing so I don't scratch my head about where I broke it.  And good advice about ASSIMP i'll take a look at it.

Am 29.01.2014 19:07, schrieb Ryan Voots:
> 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

How do you deal with GC pause times?

On Wednesday, 5 February 2014 at 09:27:50 UTC, Benjamin Thaut wrote:
> Am 29.01.2014 19:07, schrieb Ryan Voots:
>> 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
>
> How do you deal with GC pause times?

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.

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

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?

On Wednesday, 5 February 2014 at 21:37:22 UTC, Benjamin Thaut wrote:
> 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

I actually saw your webpage after some googling about d's garbage collector.  What I'll probably think about doing when I get the engine running is make it easy to do that kind of change like you're doing where you can bring it in and out since it could be great for performance but might really hurt development time.  One of the large reasons I wanted to go with D was because of the GC helping deal with a lot of the boilerplate stuff I kept dealing with in previous iterations of the game i'm making (long story short it's had about 30 rewrites/redesigns because i can never make up my mind).

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.