Author
Topic: State of OpenGL ES2.0 support (Read 24089 times)

I had two evenings to spare and started working on it. My idea is to implement it in a way that it appears as ES 1.1 to the engine, so that jPCT's actual renderer needs no big changes and one codebase can serve both worlds. So far, it's working fine...but there's no support for anything else than one layer of opaque textures for now, no lighting, no fog, no nothing...

The test scene in all it's ES2.0 glory:

One bugger: Because of Google's stupidity http://code.google.com/p/android/issues/detail?id=8931, it doesn't work with anything below 2.3...at least not if you intend to use VBOs. I'm not sure what Dalvik does if methods are used in a compiled class that are never called, so maybe it'll work in 2.2 too but without VBOs...i'll care about that at a later time...

It's now stable enough to run An3DBenchXL...it works fine, but it looks awful, because i'm still using my very basic default shader which supports virtually nothing but simple texturing.

Therefor, the benchmark results have to be taken with a grain of salt, because neither the fully featured shader nor the Java code for processing lights, fog and material are in place right now. It scored ~30000 points while the OpenGL ES1.1 version scores ~27500 points...but with much more gpu features used, so this will change. But at least it's not slower for now...

My first goal is to make it behave like jPCT-AE when run on ES 1.x...that's difficult enough. Then, i'll open the shader support to anyone (just like desktop jPCT does, but maybe in a different way). What you do with the shaders...well, that's up to you. I'll open the default shader as well, so you are free to fiddle around with it. Concerning shadows, shaders alone don't cut it. You'll need to be able to render into the depth buffer...that's another story...

Shaders on mobile devices..LOL! I thought that it might be a good idea to implement some phong lighting instead of the fixed function pipeline's vertex lighting...not good. The per-pixel operations needed for this kill performance. With only four lights, you are down to one digit fps numbers on the Nexus S..back to good old gouraud shading, i guess...

Some performance figures taken from the Nexus S. These are from An3DBenchXL. The tests are all running fine, just the multi-texturing in the Ninja test isn't supported right now, so it will get worse...

Why is that? Well, as you can see, high polygon tests (dragon and island) suffer the most. I guess that's because a high polygon count means a high vertex count, which means a lot of calls to the vertex shader. The most expensive part of the vertex shader is the lighting, because it requires some dot-products, which seem to be slow. If you remove the light source from the tests, it runs much faster...

So..well...this is a bit disappointing, but i actually expected something like this. Too bad, that you can't mix shaders and fixed function as you can with desktop OpenGL.