LWJGL and Android

[Mylo]

Hey, I want to develop a 2d 'command & conquer' style game for Android. LWJGL seems like a good library to use as i'd like to use OpenGL for my 2d graphics.

However, can LWJGL be used for development on Android? I'm assuming it will be possible as Android applications are written with Java, although I havent looked into it so I may be wrong...

If it turns out it wont be possible, are there any work arounds which will enable me to use LWJGL?

Thanks

[princec]

What's missing is:
a) A proper OpenGL ES version of LWJGL
b) Native code at the back end on the particular Android phone

We need to perhaps talk to Google about having them support LWJGL in Android.

Cas

[Mylo]

What's missing is:
a) A proper OpenGL ES version of LWJGL
b) Native code at the back end on the particular Android phone

We need to perhaps talk to Google about having them support LWJGL in Android.

Cas

Thanks for your reply,

I must admit I havent used LWJGL, OpenGL or developed any games other than a few in J2ME so i'll have to read up and look at a few tutorials before I can go any further with my plans anyway.

Ultimately however does this mean I wont be able to use LWJGL within Android?
How much work would it take to get LWJGL working with OpenGL ES?

Thanks

[kappa]

In LWJGL's current state you won't be able to use it without some modifications. However do have a look at the Slick Project, its a 2d gaming library in Java which uses LWJGL. The author of which did some work to make it work with Android, not sure how far it got though. The project homepage is http://slick.cokeandcode.com and the relevant post is http://slick.javaunlimited.net/viewtopic.php?t=703&highlight=android

[raft]

What's missing is:
a) A proper OpenGL ES version of LWJGL
b) Native code at the back end on the particular Android phone

b) Native backend is now available. OpenGL ES 1.1 and 2.0 are now available via JNI. see this blog post

[MichaelEGR]

Greets folks...

Yowzer.. I finally registered on LWJGL forums.. Woot.. My bad.. Should have years ago.. I'm "Catharsis" on JGO and been active there off and on for ages.

I've always been very appreciative of the LWJGL community and would like to continue this discussion on supporting LWJGL on Android and in particular OpenGL ES 2.x support. As things go I'm sure Google and the Android team will not extend an open hand just like Sun in integrating LWJGL, but that doesn't stop things at all. LWJGL can be available as a 3rd party binding just as it is with with the desktop.

All that is necessary to get things working for Android app development is a Linux binary (.so) with the native/binding code and additional jar file with the wrapper. For Android even if developing on Windows all you need to do is drop the .so and jar file into the libs directory of an Android project, compile as per normal, and it's golden. I'm currently investigating in adding additional Java side support to Kwaak3 (a native port of Quake3 port) in this manner, so I know an LWJGL Android binding can work in the same fashion.

I would like to work with the LWJGL community to create a 3rd party binding for OpenGL ES for Android. I can try and take the initiative on this _soon_, but would be very excited to work with the knowledgeable folks of the LWJGL community that already work with the binding generation and such for the desktop. While I mostly work at the Java level I'm not afraid to get my hands dirty with binding specific work, but guidance alone with how to make it compatible with the LWJGL build process would be fantastic. Of course I'd like to see it be a blessed LWJGL community binding as well.

I firmly believe that acting on this right now will garner a decent amount of exposure for LWJGL in the Android community as Google is seemingly dropping the ball regarding Java OpenGL 2.x support. At best the only statement made and this comes from Romain Guy is that the Java API _"should"_ available in FroYo (Android 2.2). There isn't even a strong statement saying it will be supported in the next Android release which is kind of sad really.

The thread on the Android developers list is here:
http://groups.google.com/group/android-developers/browse_frm/thread/5e93f608ddaa10b1/ecc27511ceb8b639#ecc27511ceb8b639

This however is not acceptable because even if it is supported in Android 2.2 that OS won't hit the larger ecosystem for 6 months to a year. We desperately need a 3rd party OpenGL binding on Android and LWJGL can be that solution. Again no need to coordinate with Google on this one. No disrespect to the Android dev team; Android is fantastic, but leading edge Java real time app & game developers on Android can't wait 6 months to a year for OpenGL 2.x API support especially when there are several and plenty more 2nd gen Android devices coming out this year that already have the hardware support.

So who do I need to talk to and how can we continue this discussion. I really do believe LWJGL can extend itself onto Android and I'd like to assist in making it so..

[MichaelEGR]

I might add I have 5 Android devices to test for compatibility that covers the majority of the Android spectrum presently. I have the G1, Ion/MyTouch3G, Tattoo, Droid, and Nexus One.. Of course the G1, Ion, Tattoo will be OpenGL ES 1.x only if an LWJGL binding will target that version.. What is really lacking on Android is OpenGL ES 2.x and will remain lacking for 6 months to a year unless the general dev community steps up. So I can make sure any LWJGL binding for Android works for the majority of the ecosystem. Right now mostly all devices in the ecosystem at least the smartphones are ARM based, so just an ARM binary (perhaps 2 one for GL 1.x and one for 2.x) will cover the majority of the ecosystem. Also it would be fantastic to look into specific bindings for particular device GPUs such as PowerVR (in the Droid) that have device specific extensions. Also there are some extensions such as the FBO extension available on the Droid et al that has Java API, but the Android team has failed to implement them or update the native support despite the Java API existing.

I can do all the testing and any compatibility adjustments in addition to even the binding work if I can get some assistance / guidance on how to do it the LWJGL way. I also have a small window until May that I can guarantee that I can put in reasonable hours on this effort. I have an extra Droid too that I can donate to someone in the LWJGL community that can step up and share the reigns and help out too. The only problem on that is that is it is a CDMA device and only works on Verizon here in the US, but wireless does work without an official mobile service plan. If I recall some or most of the folks here that do the binding work may live in Europe or elsewhere. Perhaps I can trade for a Nexus One locally and get one of those out to whoever can help step up on this one. I'm pretty serious on making this a reality before May, so let's get it going.. 

[Matzon]

There are more and more people that are interrested in adding ES support to lwjgl.

It is my understanding that its not particularly hard to do. It depends a bit on what level of integration you need.

For instance, making the full blown LWJGL work on android, would require some work wrt Display, Input, OpenAL.

However, if all we want is ES support then there are two ways:
1: Generate Java Templates, rely on existing OpenGL context code (have your android code call GLContext.useContext)
2: Generate Java Templates, add own context creation code (could get messy - not sure)

for both 1 & 2, there might be some changes that needs to be done to our generator, but I dont know.

It all sounds intriguing - especially with a Nexus one in the mix 

[MichaelEGR]

Aight... I'm back....    Mario from Bad Logic Games has already stepped up with a mostly working GL2 binding.. I'm downloading the SVN right now and will take a look.

http://apistudios.com/hosted/marzec/badlogic/wordpress/

It should be trivial now to get an LWJGL version going with an already working version available on Android as reference. So lets get it rolling. I'm all for a proper LWJGL version due to the style of the API changes itself and the fact that this community is large enough to make sure there is full support and continued support. I'm sure there may be some immediate benefits too for folks that can leverage cross platform deployment by just using the the GL ES subset in their desktop counterpart LWJGL games. It should be possible to make them cross platform compatible with Android rather easily. That is essentially how I am leveraging cross platform deployment now for GL ES 1.x between JOGL, LWJGL, and the Android OpenGL ES binding via a facade for non-core rendering code which is usually 90% or more of the code in certain types of engines (at least Auriga3D my engine that loads Quake3 assets).

So.. Yes... Lets rock and roll!  

[MichaelEGR]

However, if all we want is ES support then there are two ways:
1: Generate Java Templates, rely on existing OpenGL context code (have your android code call GLContext.useContext)
2: Generate Java Templates, add own context creation code (could get messy - not sure)

for both 1 & 2, there might be some changes that needs to be done to our generator, but I dont know.
It all sounds intriguing - especially with a Nexus one in the mix  

Just ES support is pertinent because audio does need to occur through the Android Java APIs as there are no native audio support. I understand right now for folks working native code that you have to send back audio to the Java side to send the the Android Java audio API or at least that is how Kwaak3 does it.

So yeah.. It should just be the ES / graphics / drawing code. Even the display setup perhaps doesn't need to be exactly like the desktop. Following how things go with Mario's / BadLogic's binding is organized is fine as that follows the standard Android way of setting things up essentially. As long as the main GL / GL2 API is available via LWJGL with the API mods LWJGL is known for then the majority of an application won't need to be rewritten. The basic setup code and any input and audio will simply use the Android counterparts, etc.  The good thing is that with Typhon I have a cross platform input / event system that works with JInput, AWT events, and the Android event system, so you can create an input control component once and deploy anywhere.

I can definitely try and get the Nexus One to someone who can assist; is this you Matzon? ;P As things go when I made it to the Android developer lab they handed out a Droid (already had one), so I had to buy a N1 myself. doh. I've been thinking of selling the Droid, but would be more than willing to try to trade it here in the US for an N1 and get that out to someone who can assist with LWJGL particulars. I admit I'm a bit deep in the pit with releasing Typhon by the end of April. I've got to release Typhon at that time as funds are dwindling on my side.. So yes.. My direct support is strained on working on LWJGL particulars as I'm already going to have a tough time getting Typhon out the door by the end of April.

[kappa]

i've got a nexus one

[spasi]

The main problem is how to incorporate the ES stuff with the existing GL infrastructure. I think I'm in favor of a completely distinct implementation, something that will be clean and easy to build/deploy independently of the rest of LWJGL. So instead of trying to fit everything in org.lwjgl.opengl, there should be a new org.lwjgl.opengles package, even if it means duplicating some of the existing code. Of course the context creation/management APIs will be similar and we can also use the generator for creating the ES binding (won't need any changes except adding a few ES-specific types). With the generator we can quickly add ES 1.0-2.0 and the extensions, most of the templates will be a copy/paste anyway.

As for context management, there can be a GLContext.useContext equivalent and then there will be the OS/device-specific context implementations, starting with Android.

[spasi]

I just read Mario Zechner's reply and checked his binding. I can see why Google's having trouble with getting a binding out, they use the "JOGL way" of exposing stuff as instance methods instead of static ones. Which, frankly, is a mess. Especially since ES 2.0 is already not forward compatible with ES 1.x. I don't understand why people try to force a pure functional API down the OO road. It's not like you can't use static imports on Android.

So yeah, that's an extra reason to provide some LWJGL goodness to Android devs.

[MichaelEGR]

I can see why Google's having trouble with getting a binding out, they use the "JOGL way" of exposing stuff as instance methods instead of static ones. Which, frankly, is a mess. Especially since ES 2.0 is already not forward compatible with ES 1.x. I don't understand why people try to force a pure functional API down the OO road. It's not like you can't use static imports on Android. So yeah, that's an extra reason to provide some LWJGL goodness to Android devs.

Right.. In Typhon I pull away the GL context for JOGL and Android and make it statically available. No reason one should pass around a GL context object and all..

For sure.. Yeah.. Honestly I don't think there was much forethought with the initial GL implementation for Android. They did it the dead simple way, and quite likely the "JOGL way" may have followed some folks to the Android team. I knew from day 1 working with GL on Android 1.0 they screwed themselves royally. There are other areas of Android where it's obvious things are tacked on and not architected well. Multitouch support is one of those areas, but there are subtle things all over. There are also areas where they almost completed stuff, but moved on and forgot it. Heh... and the Android bug tracker. There are bugs in there still marked new after 6+ months that should have been examined. Don't even get me started about the 2.0 release that was buggy as hell and rushed out the door before it was fully baked; hence 2.0.1 a month later. The GL implementation in Android 2.0 was so broken and they changed how some underlying GL methods were implemented without telling anyone. Granted they changed them to the OpenGL spec, but that so royally screwed all of us who had custom context creation code and left us scratching our heads why things failed.

Overall Android is fantastic, but yes, there are various pain points and clearly it's 80% engineering, but compared to any other embedded device / smartphone situation it's peaches (just sometimes in a bowl of gravy)..

So yeah.. I'm all for LWJGL on Android. As I mentioned I may not be the best one to guide the LWJGL ES implementation, but I can test it like none other and have a wide range of Android devices.

As far as OpenGL ES 1.x besides some constants which some have GL equivalents for the most part all the method signatures should essentially be the same. I've not looked too much in detail with GL ES 2.x compared to the GL counterpart, but I'd imagine the same is true except ES removes GL functionality instead of adding anything. There are constants, but nothing else jumps to the top of my mind right away that may be all too different as far as method signatures go. Nothing in Auriga3D is different between the desktop and Android GL versions for instance.

I do fully believe LWJGL can swoop into Android right now and claim the gold long before Google will release a semi-baked official 2.x binding.

[spasi]

Ok, well, we need someone with hardware on their hands and enough time to do it. I'm not really into the mobile madness, I have an old nokia that works nicely as a watch, has an alarm and can, you know, make phone calls . I'm also going to be crazy busy for the next 1-2 months. So, if we want this soon, it's going to be either you or javalwjgl or anyone else with hardware access that volunteers.

If you go for it, you can start simple; grab the source, copy org.lwjgl.opengl to org.lwjgl.opengles and start removing stuff. There's not much to it really. Once you remove the Windows, Linux and MacOS implementations, the Keyboard/Mouse stuff and the AWT stuff it should be pretty light and you can start working from there. I don't think you'll need much help to be honest, except maybe with the build process (Matzon can help you there) and the template generation (I can help you with that, or even do it myself, it isn't much work).