www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Reviving YAGE

reply "Ryan Voots" <simcop2387 simcop2387.info> writes:
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
Jan 29 2014
next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 29 January 2014 at 18:07:10 UTC, 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

I couldn't find anything that says what YAGE is. I suspect a game engine from some of the commits.
Jan 29 2014
prev sibling next sibling parent "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
 I couldn't find anything that says what YAGE is.  I suspect a 
 game engine from some of the commits.

http://yage3d.net/
Jan 29 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/29/14, Brad Anderson <eco gnuk.net> wrote:
 I couldn't find anything that says what YAGE is.  I suspect a
 game engine from some of the commits.

It looked promising the last time I saw it (which was years ago): http://yage3d.net/
Jan 29 2014
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Jan 29 2014
parent JoeCoder <dnewsgroup2 yage3d.net> writes:
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.
Jan 30 2014
prev sibling next sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
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).
Jan 29 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/29/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 https://bitbucket.org/simcop2387/yage

Hmm.. 70MB repository. I think those binary files or whatever is making the repo big should be moved elsewhere.
Jan 29 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/29/14, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 1/29/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 https://bitbucket.org/simcop2387/yage

Hmm.. 70MB repository. I think those binary files or whatever is making the repo big should be moved elsewhere.

It seems cloning from bitbucket seems to be slow for me. Downloading the zipped version of the repo is fast though. Maybe their servers are just slow today, that's all.
Jan 29 2014
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/29/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 I've started a fork of YAGE in an attempt to revive it.

Most of the links on the yage homepage seem to be dead. But I'm wondering whether any games were made that used Yage?
Jan 29 2014
parent JoeCoder <dnewsgroup2 yage3d.net> writes:
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.
Jan 30 2014
prev sibling next sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
On Wednesday, 29 January 2014 at 21:03:00 UTC, Andrej Mitrovic
wrote:
 On 1/29/14, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 1/29/14, Ryan Voots <simcop2387 simcop2387.info> wrote:
 https://bitbucket.org/simcop2387/yage

Hmm.. 70MB repository. I think those binary files or whatever is making the repo big should be moved elsewhere.

It seems cloning from bitbucket seems to be slow for me. Downloading the zipped version of the repo is fast though. Maybe their servers are just slow today, that's all.

I'd agree about moving them to another repo. once I get it working I'll likely look at moving it somewhere else actually. its only in bit bucket because it was easy to fork there. no idea if any games of any substance were made with it. my plan is basically to get the demos going as a test of if the port is done and then work on improving it/adding features. my aims are a top-downish RPG that has been in design for roughly 2/3 of my life (coincidentally when I started programming). many versions made none finished for lack of a developed story but that has changed recently.
Jan 29 2014
prev sibling next sibling parent JoeCoder <dnewsgroup2 yage3d.net> writes:
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.
Jan 30 2014
prev sibling next sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
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.
Jan 30 2014
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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?
Feb 05 2014
next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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
Feb 05 2014
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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
Feb 05 2014
parent Benjamin Thaut <code benjamin-thaut.de> writes:
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.
Feb 06 2014
prev sibling parent reply JoeCoder <dnewsgroup2 yage3d.net> writes:
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.
Feb 05 2014
parent Benjamin Thaut <code benjamin-thaut.de> writes:
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.
Feb 05 2014
prev sibling next sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
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.
Feb 05 2014
prev sibling next sibling parent "Martin Cejp" <minexew gmail.com> writes:
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?
Feb 05 2014
prev sibling next sibling parent "Ryan Voots" <simcop2387 simcop2387.info> writes:
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).
Feb 05 2014
prev sibling parent "Martin Cejp" <minexew gmail.com> writes:
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
Feb 06 2014