OpenGL ES 2.0 support (including shaders)

[raft]

dont get too excited, only possible via JNI

OpenGL ES 2.0 support

Applications targeting Android 2.0 (API level 5) or higher can now directly access OpenGL ES 2.0 features. This brings the ability to control graphics rendering through vertex and fragment shader programs, using the GLSL shading language.

A new trivial sample, named "hello-gl2", demonstrates how to render a simple triangle using both shader types.

here is the blog entry. one good thing about new NDK is, it states OpenGL ES 1.1 and 2.0 API's (headers) are stabilized and are guaranteed to be supported in all later releases

unfortunately emulator doesnt support OpenGL ES 2.0 

there is a demo app in NDK, OpenGL ES version of San Angeles Observation. readme says it contains more than 60.000 faces and it runs ~5 fps on emulator, quite impressive. but it does all rendering in native code

[EgonOlsen]

I don't think that any common hardware supports it yet (nor do i think that it makes any sense on such a device at this time). However, once it gets more popular and supported, it's pretty easy to add shader support back into AE.

[raft]

on the other hand, exposure of native OpenGL ES api's means there is a possibility of LWJGL is also ported to Android. but i doubt it will perform any good than rendering via current openGL wrappers.

here is a video comparing IPhone 3GS and Nexus One 3d performance. both native. albeit IPhone renders faster, both performance is quite good IMHO. i doubt a Java app will come close to it without a JIT
http://www.youtube.com/watch?v=GYqZK25KU3U

[EgonOlsen]

... i doubt a Java app will come close to it without a JIT

No, not without a JIT. But that is about to come. Even if
it would only double performance on Dalvik, that alone plus the faster CPU (1Ghz compared to 528Mhz on G1/My Phone) and a FPU (i think Snapdragon has one) should result in playable frame rates without going native. What we are doing here right now is just the beginning.

[raft]

What we are doing here right now is just the beginning.

so, you believe now this will go somewhere you must thank me poking you so much

[EgonOlsen]

so, you believe now this will go somewhere you must thank me poking you so much

It might go somewhere. Currently, hard- and software on the average Android phone just aren't there IMHO. We need Snapdragon or better, at least something that includes a FPU, a JIT and a VM that can use more than 16MB if needed. What we get instead are new chipsets that omit the GPU...and people's interest in 3D on Android is below 0, even in Android related boards. However, this will improve in the future...once people figure out how to make 3D games playable on touch screens. I've tried to play some shooter on the phone. Controls were so unbelievable bad...i would never pay even 1 cent for this. I rather should get paid for playing it. What a waste of creative energy...

[raft]

I don't think that any common hardware supports it yet (nor do i think that it makes any sense on such a device at this time).

wont shaders be quite useful for animations ? they can -for example- eliminate the need to copy vertex data continuosly to native libs, dont they ? that's the main slow down reason of animations if i got it correct..

[EgonOlsen]

Depends on the shader model that is supported. Plus you don't see the modified mesh on the vm side that way, so you can't use it for collision detection for example. So yes, it might be useful but it's not trivial.

[EgonOlsen]

on the other hand, exposure of native OpenGL ES api's means there is a possibility of LWJGL is also ported to Android. but i doubt it will perform any good than rendering via current openGL wrappers.

There's no point in porting LWJGL to Android IMHO. We already have this javax.microedition.khronos.opengles.*-stuff. As long as it reflects the changes to the NDK (i.e. includes 2.0) in time, all is fine.

[raft]

There's no point in porting LWJGL to Android IMHO. We already have this javax.microedition.khronos.opengles.*-stuff. As long as it reflects the changes to the NDK (i.e. includes 2.0) in time, all is fine.

seems as soon there will be an Android port of lwjgl:
http://lwjgl.org/forum/index.php/topic,2818.msg17995.html#msg17995

[EgonOlsen]

What for?  Just to have access to 2.0 features earlier? That's pointless IMHO, because hardly anybody does 3D in the VM. We just advanced from crawling to walking and they are already talking about what is needed to run an iron man race. Me opinion is that by the time those features are actually useful, the build-in binding will be ready and mature. Anyway...i have no problem to support another binding, so they should go for it if they see a point in it. I just don't...

[raft]

the same reason you complain about, 3d is not in priority list of google ES 2 support will be at least 6 months later.
i had quick glance to that post, they also complain about some bugs and rubbishy of JOGL style binding (with non static methods)

[EgonOlsen]

the same reason you complain about, 3d is not in priority list of google ES 2 support will be at least 6 months later.

I did complain, yes...however, i do understand this. Hardware's power is similar to what we had around 1995 at best, fillrate is even lower. Dalvik's performance currently sucks donkey balls and posting about 3D in an Android developer forum is like talking about quantum theories in an elementary school. It's so much out of scope of 99% of all Android developers, that it absolutely doesn't matter if 2.0 is supported or not, because there's nobody to support it for. Look at the normal jPCT...how long did it take before shaders were available!? And now that they are, how many people are using them...none, and that includes me (albeit i've created a little demo application at work that uses them, so it's actually none+0.5).

i had quick glance to that post, they also complain about some bugs and rubbishy of JOGL style binding (with non static methods)

I think that both methods have pros and cons. For AE, you feed the GL context into the frame buffer, for the jogl-renderer of the desktop jPCT, i'm using reflection to inject the context instance. So yes, the static way seems more like GL actually works, but on the other hand, it makes using different contexts at the same time virtually impossible, which is why the AWTGLCanvas is still there, because it's the only part in LWJGL that allows for this, with the drawback of being bound to the awt event dispatch thread.

[raft]

...however, i do understand this. ... It's so much out of scope of 99% of all Android developers..

ok, i agree. for same reason i think a lwjgl port will be valuable. it may be one of the main reasons google exposed native open gl libs. they -in some means- give the responsibility of open gl to community.

if such a port exists, it will possibly be ahead of (much up to date i mean) android api and will be maintained better. bugs wont need to wait their turn among other -important- android features

[EgonOlsen]

Maybe you are right...we'll see how it works out. After all, having more options to choose from can't be a bad thing.

A little of topic: Are you planning to get an actual phone?