Mailing the Google

about the JNI bridge i wrote. Robert from Battery Powered Games encouraged me to send a mail to Jack Palevich, the Google engineer who is responsible for GLSurfaceView among other things. In my mail i explained what i did, how i did it an offered to clean it up according to Google standards so it can be integrated into the next SDK release. I didn’t think they’d accept it but Robert pushed me to try anyways. Here’s the answer from Jack:

Wow, I am impressed by the work you have done, and I agree that it would be a reasonable way to support Opengl ES 2.0 in Android.

Unfortunately, we have already written a Java OpenGL ES 2.0 binding, which we hope to ship in a future release of Android.

From your description of what you have done, I think we were thinking along similar lines. I guess the good thing is that you should be able to switch from your version to the standard Android version when it becomes available.

I am sorry that we couldn’t accept your Android source contribution.

Best wishes, and good luck with your further Android projects,
Jack

Being the talkative guy i am i of course replied:


No biggie, i actually wasn’t sure if it’s a good idea to mail you about this. Robert pushes me :). Good to hear that the official bindings are on their way. I only put a couple of hours into that bindings so it’s not really a loss for me. Thanks for the reply and keep up the awesome work!

No further spam from me,
Mario

and Jack replied back!


Wow, you work faster than me — my version of the bindings took a week or so to write.

Next time maybe I should ask for contributions from the community before I do the work myself.

Awesome, Google talks back to you if you ask kindly it seems. What i can take away from this is that my “design” of the JNI bridge is aligned with what Google itself brewed up. So if you use the JNI bridge now you should have no problem switching to the official bindings once they come out. The ETA for those is sometime this year when Froyo, the next Android release, is published.

8 thoughts on “Mailing the Google

  1. Yeah.. Google followed the “JOGL way” of doing it via instance methods on a GL context object. This is sort of an easy way to do it but perhaps not the most clean way to force a functional API into an OO box via codegen (stub generation). So your implementation is done the same way essentially and that is also why I am excited. With my Typhon middleware which supports JOGL, LWJGL, and Android OpenGL ES I simply store away that context for JOGL and Android GL and make it statically available. Even better is that I have a facade component that creates a common API between the various binding APIs. Now how successful that will be for GL 2.x we’ll see.. All I have to do for the most part when the Android GL 2.x API is out is change my package includes since I statically reference the GL context I’m not passing around your 2.0 context object or Android’s context in the Typhon API.

    Heh and you are a bit more polite than I am these days.. I think I’m just a little too battle worn on the Java gaming desktop tip and my experience with Android using GL from day 1 which has had it’s ups and downs. This has led to a little less tolerance for any delays or in this case holding up a release for developers. Next gen titles will take some time to develop and won’t appear overnight at least detailed ones. So waiting for Android 2.2 to be released and make it to the ecosystem is not the best strategy for Google to ensure next gen Java titles being ready when it actually is released to the general public.

    Romain should have stated directly that Google had a solution and it was going to be included in Android 2.2 not that it “should” be. Simply not being clear about a time line for release is a little frustrating.

    Good work again and best of luck with your game dev efforts.

  2. I agree that the hierarchy of GL interfaces is not an ideal solution. Even more so as GL ES 2.0 is completely incompatible with GL ES 1.x. I wonder how you want to achieve a common facade for that. Just to give you an impression: there’s no vertex arrays and no matrix stacks. The shading language on the desktop is different to the ES shading language, even incompatible in some respects, e.g. a fragment shader in ES demands a precision qualifier. The definition of that qualifier will be something any desktop glsl parser will choke and die on. I poked around a bit on your side to get some info on Typhon. Sounds like a nice project (and a pretty old one. 2006 at Java One? Wow!). Is there any chance of getting a glimpse at the API?

  3. I’d be glad to get you in on the closed beta for Typhon in fact you’re the perfect kind of developer for the closed beta. I’m trying to tie some things up by the end of March and get it out to about 20 or so folks before a full release at the end of April early May. I’m also launching a web site with in depth GL tutorials with lots of sample code and videos for each tutorial.

    Typhon actually started in 2003 and I never released it for the desktop as there was no ROI potential outside of it being a nice academic / architecture experiment (dual support for GL bindings, etc.). Also at the same time there still were major holes in regard to final component architecture directions to support. For instance I long heard about OSGi, but there simply wasn’t good Java API / project support for it until around ’07 (I picked Apache Felix). Previously I was using a home grown project from Sourceforce called GenericPluginEngine and while cool it wasn’t the final / right tech for mainstream adoption.

    One of the neat things about OSGi and how I architected Typhon is that the core Typhon distribution is split up into about 30 pieces. One only needs to pick the pieces necessary to support the app or engine at hand. The core runtime / timing API has no dependencies, so one can just grab that by itself or combine it with a lot of supporting middleware / 2D / 3D engine supporting tech. For Android specifically I’ve also taken time to try and address fragmentation concerns regarding OS distribution and device hardware constraints mostly surrounding input control.

    Here is a link to a very early white paper on Typhon (then called SCREAM) from ’04:
    http://files.egrsoftware.com/site/research/whitepapers/scream_whitepaper.v1.1.1.pdf

    Typhon was originally called SCREAM and was built for real time control of audio / DSP engines and to make real time GUI software. I luckily started the project and had a goal of getting it to run on 500mhz / 256 meg laptops and older computers, so all of the techniques I developed back then work amazingly well on Android today, so I’m so excited to get this work out and have it be applicable to today’s engineering reality.

    My audio GUI interface desires is also why I’m such a stickler around multitouch support (as seen on Android & Me posts) ;). There are so many creative applications that full multitouch opens up it’s insane. The fact that my Android device _also_ has phone service is bonus.. ;P Essentially forget buying a $2k + Lemur when you can have any number of Android devices providing full multitouch interfaces (granted it’ll be great in a few years as they become more of a commodity). Also I can’t wait to host an experimental music social happening where folks can download or install OSC (open source control) apps to their Android device and interact with a music installation solo or in groups.

    Yeah.. I haven’t dug into too deeply the differences between programmable GL and GL ES on the 2.x direction. I have a feeling there will be some issues, but there should be a clever way around things on the software architecture front.

    I’ll be in touch soon soon on the closed beta.. You might like to know that I’m supporting JBullet and JBox2D physics engines with Typhons entity system in addition to full interfaces for one to roll their own custom physics solution and integrate it cleanly. The JBullet/JBox2D integration may be more fully baked towards the final April/May release, but is something I’m getting into the initial beta release.

    Chat soon! 🙂

  4. Sounds very nice. However, JBullet and JBox2D are unusable on Android just so you know. I’ve played around with both. JBox2D is a mess as it permanently allocates short life-time objects that will drive the GC of Dalvik insane. JBullet performs a lot better in that regard as it uses JStackAlloc. However, both are horribly slow with the current iteration of Dalvik and i don’t expect the next Dalvik JIT compiler to do a lot better (rumors are it’s 3 times faster).

  5. I figured JBullet / JBox2D will have issues and I simply have 1st test cases worked out and nothing grand yet. Typhon does run on the desktop too and I’m just making sure that the Typhon entity system can support a pluggable physics component. As mentioned one can plug in their own custom physics code in a component oriented fashion too and this will be the best way to handle things on Android… I’m also considering evaluating JBox2D and modifying it if possible for better performance… Of course JBullet is a different beast entirely. I think it’s a good idea to make sure the entity system works with either of these 3rd party projects in order to prepare for future integration with other physics systems.

    Now I understand JStackAlloc is meant for thread based object pools right? I do believe one of the design purposes of JStackAlloc if I understand correctly is thread safety. It may be possible to improve JBullet moving away from that, but it’s the authors handiwork, so we’ll see. I’d like to support this authors work though and see where it goes.

    For Newton I assume you roll your own solution, but are there any other engines you have examined for use on Android? I understand Phys2D is slower that JBox2D, but with a nicer API for instance.

    And yes a Dalvik JIT improvement is most welcome.

  6. I only played around with the native version of Bullet. Doing physics in Java is and probably will never be fast enough in the foreseeable future on Android no matter whether the VM does JIT compilation or not. Even a 3x performance increase due to JIT compilation will not be enough. I also worry how your elaborate object system will perform on Android. I love well designed APIs, however on Android i came to the conclusion that going the clean way is almost always to slow.

  7. Well I have definitely taken the time to tune things and also have a FastLinkedList implementation of a LinkedList / List interface and FastLinkedListMap (list backed with a HashMap too for fast add/remove). Both offer recycled internal LinkedList nodes and iterators. One does have to be a little extra careful in how the iterators are used since there is no fast fail for concurrent modification and a few other limitations, but it’s not so bad. The entity system for objects such as bullets or any other short lived object can be organized as a pool that is recycled, so no object creation overhead.

    The only garbage comes from the underlying Android implementation of which there annoyingly is garbage generated both for Android2D API and OpenGL ES (float to byte buffer situation using glDrawElements and like methods).

    The entity system is a pretty heavy system with generics and interfaces as necessary. It’s not light weight per se as it was developed on the desktop and intended to be generic/flexible enough to be applicable for a variety of uses, but so far I have not seen too many issues on Android for reasonable entity counts as far as mobile games go. Ultimately the big killer always seems to be the fill rate of the GPU when doing 3D games especially for any device not Omap3 or Snapdragon based.

    I also have a Typhon event system that abstracts input events to a platform neutral system and can work with JInput, AWT events, and the Android event system. One can insert an input filter on each of the event types to change how the processing occurs say for filtering MotionEvent before it arrives to end listeners. This entire system has no object creation overhead and also allows polled input.

    I do profile and tune everything and outside of 3rd party physics engine support I do have things at a point where no garbage is generated by Typhon itself during typical run time usage. We’ll see how this plays out in the effort to be generic / expandable enough and run time speed. The great thing is that if it’s too much overhead the Typhon entity system is just one of many components that can be used or ignored/removed without affecting the usage of other parts of Typhon if it is necessary to roll ones own lightweight entity system and still use the rest of applicable parts of Typhon.

    So yeah.. I’ll be in touch soon on the closed beta..

Leave a Reply

Your email address will not be published.