LibGDX 0.9.7
Monkey Archive Forums/Monkey Discussion/LibGDX 0.9.7
| ||
| http://libgdx.badlogicgames.com/news.html I don't know if Monkey will officially support Java Libs one day, but if LibGDX was ported it would make senses. I remember Samah was starting a port of LibGDX but stopped because the performances was equally the same on Android. Too bad cause it's a real alternatives with tons of stable features! Plus next version will support iOS backend :) Would be great if in the next version of Monkey someone could write an extended documentation on targets. |
| ||
| I might take another look at it, but I have a lot of other things in the works at the moment. One of the problems is that LibGDX is mostly based on sprite batching, and Mojo is not (though it performs its own pseudo-batching, kinda). I managed to get a compiled app up and running, and had some basic rendering working, but it was hard to do without hacking the Mojo source (not public domain). Also note that most of LibGDX's extra features fall outside the scope of Mojo, so they would need to be in a separate libgdx package. As soon as you start adding platform-specific packages, it defeats the purpose of cross-platform compilation. That's not to say it's a bad thing, just that if you use the LibGDX features you're immediately losing support for other platforms. |
| ||
| Ho... So you were not talking about a "direct" port of LibGDX to Monkey but rather using Mojo as a frontend for LibGDX. But since LibGDX support Windows, Mac Os, Linux, Androïd, HTML5 and soon iOS it's not like if you were missing a lot. Right now, this engine as so much to offer that it would make a perfect companion for Monkey. I'm nearly sure it will need a lot of time for the Monkey modules to reach that, if it ever reach (or need) that point! Do you think everything as already been made to support external libs in Monkey? I don't find any official information on this. |
| ||
| Why use it as a companion? If it offers so much, why not use it instead of Monkey? |
| ||
| I think about it. I'm much more used to the BlitzMax syntax than Java (even if the differences tend to diminish). The best of both worlds would have been a blast. In fact, I would love to know if Monkey will receive updates to easily support external libs or at least a good documentation on how to do this. Cause if not I know it will finish like BlitzMax. |
| ||
| After a quick look I'm not impressed. Anyone who ports box2d to another language and thinks it's ok to remove the original authors name and modify it's license with a less permissive one is not ok. |
| ||
| My understanding is that LibGDX accesses native box2d via a JNI layer. It's not a port and they've not attempted to change the license. |
| ||
| What? Note how I said I had actually taken a look at libgdx? |
| ||
| So have I. Here's one of the LibGDX interface files: https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/physics/box2d/Body.java Notice the JNI references and general "glueyness". Here's one of the included native files: https://github.com/libgdx/libgdx/blob/master/gdx/jni/Box2D/Collision/b2BroadPhase.cpp Notice the entirely intact Erin Catto license text. |
| ||
| OK, not that clear cut then. My quick look was based on the 0.9.7 zip distribution. Box2D internals may be present in binary form only in libgdx but the fact is they have incorporated all the documentation and API calls of Box2D into their product without any acknowledgements whatsoever. Reminds me of the story where at GDC Erin stood up and asked angry birds guys who wrote their physics. They may legally have not been required to include any attribution or acknowledgement but it still makes them smell bad in my book. |
| ||
| Erin Catto asked if AB would credit Box2D as the physics engine used. LibGDX doesn't hide the fact that it uses Box2D or neglect to mention it. Box2D physics is openly stated as a feature. I really don't see a problem here. |
| ||
| I agree ( I'm unable to disagree without looking like a total hypocrite ). |
| ||
| ... Okayyy Reminds me a few situations like when a jury had a "quick look" at months, if not years, of works and someone say : I'm not impressed. The name kinda make sense now ^^ |
| ||
| I'm actually more interested in the libgdx implementation of box2d than I am with libgdx itself -- I'm curious as to what sort of performance improvements there are by using JNI for the thing. The author (one of the authors?) of libgdx appeared to have announced he was using it of it on the box2d forums when he wrote the wrapper, so it's not like it wasn't mentioned: http://box2d.org/forum/viewtopic.php?f=5&t=5589 AFAIK, the monkey port of the as3 box2d engine has been the only attempt thus far at porting box2d to Android in a "managed" way. My initial tests on Android have produced some interesting performance results which I didn't notice before on non-Android platforms that might make JNI interesting to take a look at. Unfortunately, as of v66b, it appears that it's not possible to import packages using externs and direct file imports due to where trans injects Imports. I don't know if the situation has changed with v68 but having a special way to allow for this without recompiling trans would go a long way toward utilizing external libraries on the android target (and making full cross-platform static linking of external libs possible) |
| ||
| I compared them a while back here: http://pointlessdiversions.blogspot.co.nz/2012/03/monkey-vs-libgdx-box2d-performance-on.html The latest version of the Monkey port is considerably faster and within about 30% of the LibGDX version on the same test. Edit: Actually < 20%. I added an update post: http://pointlessdiversions.blogspot.co.nz/2013/03/update-on-box2d-performance-vs-libgdx.html |
   |