In case the author gets to read this, the site needs a clearly-labelled "Features" page. I'm not going to waste time watching half a dozen youtube videos or trawling Javadoc'ed source code. Sell it to me, tell me what it can do.
@teamonkey thanks for the hint, now that you said it, its pretty obvious I need a dedicated "Features" page =)
@zyb09 LGPGL is a free license! Google it!
@zitterbewegung The Augmented-Reality is not well tested, because in pretty much every Android version, stuff that is needed for the extension was changed.
I thought the LGPL required you to allow the user to update the library to a newer version (usually accomplished by making it a dynamically linked shared library). Near as I can tell, Android doesn't yet support user installed shared libraries. Does this mean the engine is only usable from GPL and LGPL Android apps?
The LGPL doesn't require in-place modifiability, just that a user could build a working binary from a newer version of the LGPL'd library and your binary, along with appropriate dev tools and assuming no interfaces have changed. For statically linked C code, the LGPL suggests providing a linkable object file (.o) that the user can use to relink against newer versions of the library. I think that's already the case with Java apps by default, though, because a user can just dump new versions of the library's .jars in to your app, overwriting the old version. Even if you've slurped everything up into one big .jar, they can still extract the new .class files into the .jar, overwriting the old ones. Then they sign the app with their own key and install it on their phone.
In practice though most LGPL-software authors don't even seem aware of this clause (I wasn't until recently) and aren't inclined to enforce it. A bunch of LGPL game libraries, like Ogre3d, have explicitly added a "you can statically link with no hassles" exception, to formalize that understanding. Might be a good idea here?
The examples look very interesting. This seems to be well developed considering the time they have put into the library and the examples. I haven't seen anything like this for iPhone and its great that it is free. I did encounter one of the examples crashing (augmented reality) and this was on a Motorola Droid
Actually the iphone Cocos2D is much further along in development than any of the android engines. Also, if you are referring to this cocos2d port here: http://code.google.com/p/cocos2d-android/
it is a buggy and rather useless port due to the liberal use of temporary object allocations which totally chokes the garbage collector on dalvik
This is exactly what I needed! The canvas is too damn slow, and open GL is too confusing and close to the metal.
I have been putting off my game for over 3 months because I knew I would have to write this first, now I don't! Thanks!
The problem with rokon (when i looked at it) is that it runs both the rendering and game logic on one thread, which is not optimal for performance. AndEngine takes this a step further by running it on 2 threads and only locking them into sync during the geometry submission phase of the rendering pipeline. By doing this, you save about 10-12ms per frame to do your game logic while an eglBufferSwap is happening (on my Mytouch3g), which in some cases can cause a big speedup for your game.
