www.jpct.net
jPCT-AE - a 3d engine for Android => Support => Topic started by: raft on March 09, 2010, 04:50:17 am
-
dont get too excited, only possible via JNI ;D
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 (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)). 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 (http://jet.ro/visuals/4k-intros/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
-
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.
-
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
-
... 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.
-
What we are doing here right now is just the beginning.
so, you believe now this will go somewhere ;D you must thank me poking you so much ;)
-
so, you believe now this will go somewhere ;D 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...
-
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..
-
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.
-
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.
-
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
-
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... ;)
-
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)
-
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.
-
...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
-
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?
-
After all, having more options to choose from can't be a bad thing.
impossible to disagree
A little of topic: Are you planning to get an actual phone?
no concrete plans yet. if i decide to do something for android, i will certainly need one. but the thing is, living in turkey has disadvantages on this thing too. nexus one isnt sold for this reagon at the moment ::) i dont know any other model sold around/for here. my friend has a tattoo and g1, tattoo is sent him by a company and g1 is bought by a friend living in usa.
speaking of the witch, google gives a free android phone (g1 i suppose) to all who has an app in android market with 5000+ downloads. my friend's dictionary app has 900.000+ downloads but he cant get one because he lives in turkey >:(
-
..i dont know any other model sold around/for here.
i must correct myself here. this is defintely not the case, there are htc and samsung models for example
-
Just ordered a Milestone. So I can help with any testing when I get it...
-
Cool. Can we force you to write some game or something for it somehow...? ;D
-
Sure :)
Was not cheap, had to get a special one from Canada to work on my network. So will be looking into creating some apps and putting it on the market.
-
Sorry to dig up an old thread but I noticed a few 'WTF' comments in the default jPCT shaders, perhaps this info can help;
Varyings are used for passing data from a vertex shader to a fragment shader. Varyings are (perspective correct) interpolated across the primitive. Varyings are read-only in fragment shader but are read- and writeable in vertex shader (but be careful, reading a varying type before writing to it will return an undefined value). If you want to use varyings you have to declare the same varying in your vertex shader and in your fragment shader.
All uniform, attribute and varying types HAVE to be global. You are not allowed to specify a uniform/attribute/varying type in a function or a void.
Ref: http://nehe.gamedev.net/article/glsl_an_introduction/25007/
-
I know that. The WTFs refer to some shader compiler choking on loops and some optimizing away the whole shader is some cases. They have nothing to do with varyings in the first place.