Will jme be compatible with Android? IT uses open es as backend.
That depends on how much of OpenGL ES is made available to the Java side of things. Considering there is a JSR for OpenGL ES, and the fact that Android is an open platform, that should only be a matter of time. (edit: looks like this is covered http://code.google.com/android/toolbox/apis/opengl.html ) After that, jME should make a custom OpenGL ES renderer.
Or as an alternative there could be a LWJGL fork… either replacing native LWJGL methods with Java OpenGL methods (if a binding is available) or using LWJGL to create a binding.
That doesn't mean you're home free yet though, since I doubt android will support all of the Java class library. Most likely it will be closer to something like the CDC profile, and apperently Google is bundeling some (ported) third party libraries, such as HttpClient.
Things like resource loading, application loading (no more Swing windows!), context creating… embedding your context, input system, and even things like usage of collections should be looked at. Though it seems Andriod will have a pretty big class library compared to other mobile phones (including most collections): http://code.google.com/android/reference/packages.html
Also, android will probably take a while before you can buy it in your average corner store. There are some phones out already that support OpenGL ES, and some even the java binding, notably the Sony Ericsson K850i and W910i. (spec link: http://developer.sonyericsson.com/getDocument.do?docId=96059). Taking into account what I said above, you could port jME to this phone. It also has a 3 axis motion sensor which could make for some intresting games.
I am getting my hands dirty with android since yesterday.
Looks very promising (I got spinning cubes!!!).
I don't think it would be a problem to make JME run on android but the different capabilities of the phones will be a problem.
But finally we get a full JVM on a phone, the micro edition always was a pain in the ass.
So just taking a look at Android initially it looks like they support their own subset of the Java API and extensions in their android.jar (NIO, OpenGL ES. etc)
So the main task to port it to jME is to create a new, AndroidDisplaySystem, AndroidRenderer, and all the *State classes that go along with that. One of the big differences with OpenGL ES is that they got rid of glBegin() and glEnd() instead all display data is pushed through array's, which is generally how things are optimized in the end anyways.
Another twist is that Android doesn't support AWT and it looks like JMECanvas references it through its setBackground(Color bgColor) method which could be changed to just use ColorRGBA with minimal impact (in fact the only method that really uses it in jME is converting the Color to ColorRGBA.
public interface JMECanvas {
...
public void setBackground(ColorRGBA bgColor);
...
}
Also it looks like the DisplaySystem is referencing java.awt.Canvas in the
public abstract Canvas createCanvas(int w, int h);
So this could be factored out into a subclass of DisplaySystem called AWTDisplaySystem that provides that method, and then LWJGLDisplaySystem can inherit from that (the only draw back is any call that want to create a Canvas needs to cast it to a AWTDisplaySystem).
AWTDisplaySystem.java
public abstract class AwtDisplaySystem extends DisplaySystem {
public abstract Canvas createCanvas(int w, int h);
}
SimpleJMEApplet.java uses the createCanvas method so they'd just use:
glCanvas = ((AwtDisplaySystem)DisplaySystem.getDisplaySystem()).createCanvas(canvasWidth, canvasHeight);
I'm still messing with Android's OpenGL capabilities trying to figure out how to load a texture so that I can map it to a cube. It appears that Android sort of provides a higher level OpenGL API, but it's completely undocumented, but it contains helper classes like:
Android GLutils Package
- GLView - This could be used as the drawing canvas and input system i believe.
- Texture - Not sure how to load this but it accepts an InputStream
- Material - Not sure how to load this but it accepts an InputStream
- Object3D - Not sure how to load this but it accepts an InputStream
- Group - Looks like some kind of scene graph node object
Here are some more Android OpenGL ES resources:
- OpenGL In Android - http://code.google.com/android/toolbox/apis/opengl.html
- OpenGL ES Overview - http://www.khronos.org/opengles/
- OpenGL 1.X - http://www.khronos.org/opengles/1_X/
- Android Java OpenGL ES API - http://code.google.com/android/reference/javax/microedition/khronos/opengles/package-summary.html
You did read the Finally, note that though Android does include some basic support for OpenGL ES 1.1, that support is not complete, and should not be relied upon at this time. message on their page right? 
Just making sure…
Haha yes I did see that and I thought that looked a little troubling, but above that they did say:
Android currently supports OpenGL ES 1.0, which corresponds to OpenGL 1.3. So, if the application you have in mind is possible with OpenGL 1.3 on a desktop system, it should be possible on Android.
So I'm thinking that means they fully support OpenGL ES 1.0 and partially support OpenGL ES 1.1 ?
Either way no devices exist with Android implemented so hopefully they'll solidify that OpenGL API (especially if developers come up with something really cool! 8) )
I only said it because you link to some weird looking GL1.1 javadocs,
While there are slightly more helpful GL10 docs:
http://code.google.com/android/reference/javax/microedition/khronos/opengles/GL10.html
What I'm personally curious about is if JNI will be supported (will Google's custom package format allow you to deploy native libraries). Anyone manage to find that out yet?
It looks like people were able to compile native programs and push them to the Android Emulator to be run:
People have been looking into packaging the native libraries using the Ant program that builds their custom *.dex files, but I think the problem is the R.java which is an auto-generated resource file that references all your resources (Images, XML, etc.) would need to be updated to understand that you want to reference your native *.so library as a resource to be packaged.
Also it sounds like some of the Android API accesses native code so that would indicate that it's possible to write native libraries, push them to the device and then use them in your Java code. (Obviously a full real example would be nice ;) ).
- JNI: native bindings to java within android
- how to make program in C++ - People are trying to find out how to call the native libraries from java although not succeeding
Thanks! Looks like there's some potential there… Of course we'll still be dependend on the security/permission settings that operators or manufactorers will ship their device with.
Thanks answered all my questions ( plus some )
I hope I can get my game to a phone of some sort, but my game is still under development.
Teaster
Well let's hope Android is done quicker than your game then 
I also think aside from Sony Ericsson's Java system 8 phones, we'll see OpenGL ES JSR support on the next Symbian Series 60 iteration as well, (After all if Sony Ericsson did it Nokia can't stay far behind), which means within a short time after that happens there will be millions of potential jME phones out there…
llama said:I think it will :) My game is going very slowly forward :( but at least it is not going backwards :mrgreen:
Well let's hope Android is done quicker than your game then :P
llama said:that sounds great! I hope they make all phones java capable, and I hope they make them java standard edition capable, and not that shitty micro editing...
I also think aside from Sony Ericsson's Java system 8 phones, we'll see OpenGL ES JSR support on the next Symbian Series 60 iteration as well, (After all if Sony Ericsson did it Nokia can't stay far behind), which means within a short time after that happens there will be millions of potential jME phones out there..
What's so shitty about it? The phone I'm referring to is ofcourse a Java ME implementation (like the other billion phones out there). OpenGL ES is just a Java API, wether it's on Microediton or not.
It's true there are a lot og bug riddled implementations around of Java ME, but trust me, there will be a whole lot more bugs if the entire Java SE library has to be supported! It's also not very realistic to expect eg. a device with 250KB of heap memory to support that…
There are some minor drawbacks (lack of 1.5 language features and such, though you can retroweave the generics and enumarations that jME uses)
What makes it so bad in your eyes?
llama said:
What makes it so bad in your eyes?
No gc.
No/few compatible API's with JavaSE.
The reason I choose Java after lot of experience with assembly and c++ was because of the easy API's, and also that I didn't need to make sure it worked on differently platforms.
After that I changed to linux too, since it doesn't matter if I program for or in linux, mac, windows, etc.
I don't really bother to learn so many new apis for a phone I nearly adapted to all of the jSE yet.
Sorry if it offends you, but I find jSE very bad, in theory it would be great but in practice it is bad.
Teaster.
EDIT:
Of course I know they can't make it swing compatible, but they could really do lot to make it close to swing compatible and reuse lot of classes.
Swing would be a terrible way of doing input on devices like that. Android isn't doing Swing (or anything like it) either…!! Phones simply require a different kind of UI api… even if you just think of all the different input methods! With Canvas you can make any UI you want. With more modern phones you can use the SVG JSR ( http://jcp.org/en/jsr/detail?id=226 ), with which you can make a flash like UI.
If you miss any of your favorite standard API's like the collections, just copy them from GNU Classpath or from the Harmony project… that's definatly the first thing you'd have to do for a jME port.
Ok, it takes a little extra work here and there… but c'mon… you're just being spoiled here! You expect a device with a 100 times less storage and a 100 times less processing power than you're desktop PC to behave in the same way. I've programmed for Java devices with just 96 pixels, that's about what those ugly default Swing them uses for drawing borders on your windows
Anyway, you don't have to like it… unless you want your game to run on those millions of phones of course
llama said:
Swing would be a terrible way of doing input on devices like that. Android isn't doing Swing (or anything like it) either..!! Phones simply require a different kind of UI api.. even if you just think of all the different input methods! With Canvas you can make any UI you want. With more modern phones you can use the SVG JSR ( http://jcp.org/en/jsr/detail?id=226 ), with which you can make a flash like UI.
I am actually starting to like fenggui more than swing :)
llama said:
If you miss any of your favorite standard API's like the collections, just copy them from GNU Classpath or from the Harmony project.. that's definatly the first thing you'd have to do for a jME port.
Well thats what I miss, or would miss when porting or programming at all to a phone.
Changing to gnu could be a idea, however it is not fully compatible with 1.5 and sun will be releasing java 1.7 soon - that makes it like 2 major versions behind.
llama said:
Ok, it takes a little extra work here and there.. but c'mon... you're just being spoiled here! You expect a device with a 100 times less storage and a 100 times less processing power than you're desktop PC to behave in the same way. I've programmed for Java devices with just 96 pixels, that's about what those ugly default Swing them uses for drawing borders on your windows :P
Yes I am being spoiled ! XD but seriously they can do Voodoo in sun labs, I guess they could find a good solution :)
Beside I am using ubuntu not windows, I really dislike anything about microsoft except they got money :wink:
llama said:
Anyway, you don't have to like it..... unless you want your game to run on those millions of phones of course :D
Well I don't have to like it for program it, but it really helps to like programming it.
Teaster.
Harmony IS an implementation of Java SE 
The difference is they use a more liberal source code license, so you can take their code if you feel you miss a class when you're building something for a Java ME phone, instead of grieving how much you miss it
llama said:
Harmony IS an implementation of Java SE :) The difference is they use a more liberal source code license, so you can take their code if you feel you miss a class when you're building something for a Java ME phone, instead of grieving how much you miss it :)
I will think of it for my release of my game, so I could distribute the client with vm and classes with out no worry if I edit classes etc, this would make it very easy for people to play. Just download for windows/linux and start the executeable file.
But for now I am quite happy with the jSE.
Can you tell me if there is many bugs in Harmony?
Teaster.
You don't need harmony for that. You can do that with the regular JRE from Sun (even for the non-opensource JRE this is allowed). Again, I was purely talking about using harmony classes when porting jME to Android or Java ME devices.
llama said:
You don't need harmony for that. You can do that with the regular JRE from Sun (even for the non-opensource JRE this is allowed). Again, I was purely talking about using harmony classes when porting jME to Android or Java ME devices.
You can? Sweet! ... last time I checked up on that was like 2 years ago, and now when I come to think about it I didn't get a straight answer at that time.
It will take some time before even considering to port my game to Android, since I don't think any cell phones can take my game, too much cpu/ram consuming.
I've look closer at Harmony, it seems very well programmed.
Teaster.