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
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 :)
Quote from: princec on February 07, 2009, 13:42:57
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
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
Quote from: princec on February 07, 2009, 13:42:57
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 (http://android-developers.blogspot.com/2010/03/android-ndk-r3.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+blogspot/hsDu+(Android+Developers+Blog))
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 (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..
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.. ;D
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 ;)
Aight... I'm back.... :o 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/ (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! :P
Quote from: Matzon on March 13, 2010, 10:53:33
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.
i've got a nexus one :)
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.
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.
Quote from: spasi on March 13, 2010, 14:32:25
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.
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 :o. 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).
Quote from: spasi on March 13, 2010, 17:47:23
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.
Yeah.. I'm crazy busy here too unfortunately trying to get Typhon out the door. As things go Mario nailed a nice GL 2.x binding in little time and since it's done the "JOGL way" and will be very similar to the official Android binding my immediate need is at this time satisfied since I can integrate it just like I do the Android 1.x binding via a static instance via Typhon then just change the package includes later.
Quote from: spasi on March 13, 2010, 17:47:23
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).
How I'd try or at least my current thought is to simply make a reduced version of LWJGL itself without creating a new package for ES specifically. Simply cut out the Java API that isn't supported on OpenGL ES 1.x and make a new lwjgles.jar that contains the minimized API with the same method signatures as the GL counterparts. Perhaps there could be a use for putting the static constants in a GLES10 class (or similar version number as applicable), but all methods should remain in there GL10 (and like classes). This way an application already made for OpenGL 1.x can be ported to GL ES without major changes. Generally speaking the reductions in GL ES simply cut out the cruft and old or non-essential ways of working with GL (immediate mode gone for instance). There are other things of course. I'd probably not even concern myself with creating a fixed point version either as that simply isn't needed on todays hardware and such. If the same strategy as above can be applied with GL ES 2.x I'd do the same though that does get a little more tricky regarding version number compatibility between desktop GL and ES. I'd first make my Java facade component for Typhon and examine the similarities of how one can go about creating a facade component for GL ES 2.x then have that conceivably guide the process.
Of course it may be best to go the org.lwjgl.opengles route. I'm just trying to think of a way on how to make the transition for folks on the desktop so that they can leverage their work directly without much modification. It could just be useful to create a facade between the LWJGL ES packages and LWJGL ones.. I already do this essentially with Typhon and simply would add the LWJGL ES binding as a fourth supported binding/API, but it would require everyone to do a lot of changes to their code for those that would like a unified codebase between GL and ES. Hopefully just a lot of search/replace.. Folks that don't do static imports though and reference the GL10 class directly and such would have to do more work to update to a facade and yeah.. The facade would have a method call overhead.. I kind of assumed JIT may factor out the one level of redirection a facade provides, but of course that is not the case and Android doesn't have JIT yet though I understand it's coming soon.
As mentioned though with Auriga3D 98% of the code is based around a facade and the tight rendering loop is directly using the binding of choice.
Anyway.. Good discussion.. I'd like to be involved in some capacity, but as things go I do have an interim solution I need for Typhon on Android and am overloaded just getting that out the door finally.. Then I gotta rush and get 2.x support covered, so I quite likely can't take point on an LWJGL effort.. I can test it though and such if someone can get on it. I'll make sure it works on Android.
Google royally screwed up with the official GL ES 2.0 Java binding. The engineer that made the binding was unfamiliar with the pitfalls of autogen tools and omitted overloaded java.nio buffer types for glDrawElements and glVertexAttribPointer thus making VBO unusable with the official bindings. The official GL ES 2.0 bindings unfortunately are part of the Android 2.2 release and there is no hope for a fixed API until 3.0 which as we all know will not get to devices for 10 months to a year and even at that not all GL 2.x capable devices may receive an update. The official bindings are now crap and GL ES via Java continues to be a 2nd class citizen. A frustrating part is that this was caught right after Google I/O by a non Google developer with the leaked release candidate and Google was notified yet the very simple fix (updating the method signatures) did not make Android 2.2 which shipped well over a month after this bug was found.
So once again LWJGL! Who wants to get up to the plate and do a proper binding for Android! Yar.. I just haven't had the free time to start this. I just wanted to inform everyone here that the official Java bindings now have a serious flaw and it's necessary to use a 3rd party binding to properly use GL ES 2.0 features and VBO for Android.
As things go due to compatibility concerns and having to check if the OS is Android 3.0+ it's not even safe or practical to use the official bindings at all.
More info here including comments by the engineer:
http://apistudios.com/hosted/marzec/badlogic/wordpress/?p=760 (http://apistudios.com/hosted/marzec/badlogic/wordpress/?p=760)
Spasi's almost done with an ES binding I believe.
Cas :)
Quote from: princec on July 12, 2010, 11:12:58
Spasi's almost done with an ES binding I believe.
Cas :)
I read in another forum that Spasi expected this to be done by the end of Sept. I guess that was a no-go? ???
afaik, he is just not ready to announce anything. He has also been working on OpenCL - so a busy man...
Also, I think we should say also that we're under NDA about something to do with it, and no, we can't tell you who or why.
Cas :)
Quote from: princec on October 20, 2010, 11:06:23
Also, I think we should say also that we're under NDA about something to do with it, and no, we can't tell you who or why.
Cas :)
Oh interesting, didn't know you were involved too :)
So someone's signed you ppl up to write an OpenGL ES binding for LWJGL, plus as there is a NDA involved it indicates that its a large company (probably US based). Second if they want ES it indicates that the company is probably developing for mobiles and targeting Android/Nokia.
Any more information on this?
Bill
Possibly some more news on this in the next couple of weeks...
Cas :)
Did this ever get completed? Has anyone got an example project / code example to show how you would code up lwjgl to work on Android? Even if OpenGLES 2.0 support is in the lwjgl api, what native files is it going to expect for android compatibility (Just wondering how you would test it)?
Yeah, talk about leaving the thread as a cliffhanger. Good going Cas. :P