yashsingh1/xdaforums huggingface dataset:
[Nexus One Android Development] robert-qfh:
You're right, the dlopen() approach is probably the better one. The more I think about the more I like it, because it could be done as a drop-in replacement for the standard OpenGL header, plus one function that binds the function pointers to the addresses retrieved by dlsym().

Sort of like this:

Original declaration:

GL_APICALL void GL_APIENTRY glActiveTexture (GLenum texture);

Function pointer declaration:

void (*glActiveTexture) (GLenum texture) = NULL;

void init() {

h = dlopen(...);

glActiveTexture = dlsym(h, "glActiveTexture");

}

Calling the function pointer can be done using glActiveTexture(), so no changes to the code required.

What are those PowerVR helper functions? I also had trouble setting up the projection system. Main problem is probably the lack of good resources about GLES 2.0 development on the web. There are tons of tutorials dealing with GLES 1.1 (glRotate & friends) and Desktop-OpenGL (gl_ModelViewMatrix etc.). I guess you have to implement all that stuff yourself, but I find it somewhat tedious to create my own rotation matrices, projection matrix, etc. There most be an easier way, even if it's a library of shader code snippets to get started with.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Makes sense. For the PowerVR helper functions, they're in the OpenGL ES 2.0 SDK for PowerVR SGX. There seems to be two sets: PVRTools and PVRShell. I haven't done much looking into them because A: they're names include PVR so it seems a fair guess that they're power vr only and B: they're in C++, which one of the docs that comes with the ndk says is incomplete in Android.

That said, last night I bit the bullet and sat down and worked on implementing the matrix functions(the main ones we're missing, aside from texture loading) and wrote up a .h file that should be able to handle most if not all of what we want to do. I'll attach it here. I had to put it in a zip file so xda would let me attach it.

-Oh and by the way, I haven't tested those functions at all except to ensure that they compile. So testing will be necessary(and, if you'd like, a quick spot-check code review would be great).
[Nexus One Android Development] robert-qfh:
NICE, thanks for sharing! That should help anyone getting started. Especially the gluLookAt() is nice to have.

I can shed some light on the C++ on Android topic. C++ is supported, but the STL (vector, list, string, etc.) is missing. That's not a problem, though, as there's a project called STLport. Build it using the NDK and link it whenever you'd like to use C++/STL:

STLPORT_BASE := /home/robert/devel/android/ndk-wrappers/stlport

LOCAL_C_INCLUDES += $(STLPORT_BASE)/stlport

LOCAL_CFLAGS += -D__NEW__ \

-D__SGI_STL_INTERNAL_PAIR_H \

-DOS_ANDROID

LOCAL_LDLIBS += -L$(STLPORT_BASE)/build/lib/obj/arm-linux-gcc/so -lstlport

This will allow you to compile most C++ code. AFAIR some features are missing, especially exceptions, but they're rarely used in C++ code anyway.

BTW, if you ever put your JNI functions inside a .cpp file, make sure to wrap a extern "C" {} block around it. Took me one or two hours to spot that problem.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
So I've spent pretty much the whole day trying to play around with it and I seem to be having a problem somewhere, but I can't really figure out what it is. I even modified my project so I could test out some gluLookAt calls and return the resulting matrix to java to poke around. Everything in those returned matrices looks perfectly the way it should, but when I try to actually display using those same gluLookAt calls, everything ends up completely warped. The only thing I could think of is that I was screwing up on whether the matrices are column or row major. But when I change it to row major, I was unable to display anything.

Anyway, I've modified a lot of the Matrices.h code to make it easier to read and fixed some bugs I found so I'll attach that here.

EDIT: oh and the glPerspective call doesn't seem to work right now, so I'd suggest trying to just use glLookAt for now, if you're going to play around with it.
[Nexus One Android Development] NPS_CA:
GDC and Android

Any of you going to GDC; I used to have to go for work (previous company was a GPU company).

Interested in the C++ discussion they are having; wonder if they are wrapping more around NDK; Really want to push to see if we can see a true OGL ES2.0 environment in the SDK and future ROM's on the more capable GPU devices.

See: http://android-developers.blogspot.com/2010/01/android-at-2010-game-developers.html

Also; GDC conference (paid attendees) can get a Nexus One of Droid:

http://gdconf.com/androidphone.html
[Nexus One Android Development] robert-qfh:
Marcus, I think a spotted a problem in your glTranslate(). OpenGL uses column-major format, i.e. the base vectors are laid out contiguously, i.e.

0 4 8 12

1 5 9 13

2 6 10 14

3 7 11 15

The M() macro is fine, but

M(3,0) = x;

M(3,1) = y;

M(3,2) = z;

should be

M(0,3) = x;

M(1,3) = y;

M(2,3) = z;

Also in glRotateZ() shouldn't

mat[5] = -sin(rotation);

mat[6] = cos(rotation);

be

mat[4] = -sin(rotation);

mat[5] = cos(rotation);

I didn't check whether sin and cos are used in the right order with the correct sign, but a rotation around Z should leave Z untouched, therefore [2], [6], [10] are independent of the angle.

Keep in mind that OpenGL uses degrees, but C's sin() and cos() use radians.
[Nexus One Android Development] robert-qfh:
@NPS_CA, I won't be attending GDC, I'm still busy with my master's thesis and actually I'm more interested in using the GPU for doing general-purpose calculations than for game development :D Haven't done any GPGPU stuff so far, but now that we can use GLES2 it should be possible.

I guess Google is going straight for OpenGL ES 2.0, and support is probably only a few weeks away (next NDK?). I don't expect them to improve the incomplete/non-existing support for ES 1.1, just doesn't make too much sense. Those < 2.0 devices aren't designed for games anyway (GPU-wise). But it's very interesting to see that Google actually puts some decent effort into gaming on their platform...

Just for the records, while doing some research on rooting I came across the following lines in /system/build.prop:

# The OpenGL ES API level that is natively supported by this device.

# This is a 16.16 fixed point number

ro.opengles.version = 131072

For the Nexus One, this means 2.0. Not too interesting, we already knew that. But might come in handy for other/future devices :-)
[Nexus One Android Development] MarcusMaximus04@gmail.com:
For the translate: Ya, tried that. It ends up displaying nothing and no matter what values I try passing in(I checked to make sure I wasn't culling the vertices both by trying translating them in both direction along the z axis and by reversing the order of them to make sure it wasn't backface culling. Neither worked), it just wouldn't do anything. I agree with you that that's what they should be, I just can't make it display anything with those values, and I'm not sure why.

For rotation: I think you're right. I haven't tried rotating much since I'm trying to get translation working first since that *should* be a simpler operation. Unfortunately, it's just not turning out all that well for that.

Oh and I won't be attenting GDC either. Don't have the money or the time.

EDIT: OMGWTF$(!%((^(^(#^$#)^(#%&$%&$(&!!!!! I have no freaking clue why it worked, but this did. I'm going to kill someone.

M(0,3) = x;

M(1,3) = y;

M(3,2) = z;

Yes, that's right, the perfect way you're supposed to do it except with a screwed up z value. Anyway, I'll attach the updated Matrices.h here.

EDIT: may have spoken too soon. I'm not sure why but now I can't get z translation working(which was always working perfectly before). Now it just can't translate along the z axis if I leave it like that, and if I use the matrix position where the z value should go (2,3) then the whole thing breaks and I can't see anything.
[Nexus One Android Development] NPS_CA:
In my previous life I worked on mobile GPU architecture. I'm three years removed from that now. Bottom line is that the 3D Core Qualcomm licensed has OGL ES 2.0 support in the snapdragon product line. So Agree; 1.1 is more casual 3D - NOT gaming centric (e.g. UI, etc). I see if Google is serious they will make a push to show OGL ES 2.0 at GDC in some development form. I like the fact that Droid and Nexus One are two of the giveaway handsets; gives some encouragement that apps will likely be compliant with the embedded GPU's on both for any dev plan Google has.

Google really needs to get off their duff in the Android team and ensure they put together a good dev rel program - bring on board some key ATI/NVIDIA dev role folks who can help bring some key Tier 1 mobile developers on board.... Man even the pathetic Palm guys are showing some good content now on Palm Pre/Pixi.

GPGPU/Mobile CUDA style programability for the GPU is VERY interesting for some non graphics apps; (e.g. image processing, etc)
[Nexus One Android Development] MarcusMaximus04@gmail.com:
FINALLY!!! It took all freaking day, but I finally got the stupid Matrix math stuff perfectly. Note that you'll need a projection matrix(courtesy of my handy glPerspective function), you might want a view matrix(courtesy of my handy gluLookAt function), and whatever world matrix you want(courtesy of glRotate.., glTranslate, and glScale), in that order. It took a while to get everything to look right even when I finished modifying the actual matrix functions just because I couldn't remember where to put certain parts. Anyway, enjoy everyone.

I'll attach a little sample of an app using some of these functions, along with the Matrices.h file and the function used to draw the sample app(not attaching the whole file because I have some proprietary stuff elsewhere in the file).
[Nexus One Android Development] robert-qfh:
Very nice. thanks Marcus. I implemented the dlopen() + dlsym() way of loading the library. Works nicely, didn't test on a Droid though. Find it attached, the file is called gles2wrapper.h and meant to be a drop-in replacement for gl2.h. If you have several .c/.cpp files calling gl() functions, you will have to copy the variable declaration to a separate .c file and make the declarations in the header "extern", otherwise you'll probably get duplicate symbols.

There are Eclipse projects in the sample folder, and another (CDT) project in the jni folder.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Awesome. That should help a lot. On the Droid side, there seems to be(I've had only 1 report back from anyone with a droid) a problem, but I'm not entirely sure why. The guy got a cursor finalization error from NativeStart.run(tried to finalize a cursor that wasn't closed) and ended up with just a black screen, but I have no idea what that means or why it would only happen on the Droid. I put up a request for assistance a couple days ago in my thread in the general android development forum, but haven't gotten a response. Unfortunately, I don't have a Droid to test on, so I can't verify anything. (Although there's a 50/50 chance of that changing in March-- I've decided to go to GDC after all)
[Nexus One Android Development] blunden:
Agreed. That would be really interesting to see. :) You would have to consider the battery drain of the GPU in full load though I assume. Hopefully there are lots of things that could be done using the GPU that won't drain too much. :)
[Nexus One Android Development] Jibreil:
Google needs to enable installing Apps/Games on SD Card for true OpenGL ES 2.0 games to publish on the market as these games vary from 100MB to 200MB in file size and installing on phone memory doesn't leave much room for other apps.
[Nexus One Android Development] d1mbu1b:
frame rates and openGL/JNI architecture

What frame rates are you all seeing with this DemoActivity code.

I have setcpu to 1GHz and I am getting 7.25 fps with san-angeles.

I was extremely disapointed expecting at least 30.

I have yet to learn the android application stack.

So I dont know if its a JNI issue or simply thats what the render rate is.

I am concerned since I am porting an ES implementation.

I am trying to decide to pass the context and surface once to a JNI thread and do all the GLES code by hand and control my own frame rate;

or do it the way the san-angeles example does it and allow the GLSurfaceVIew and Renderer to hike up and down the JNI stack each frame.

Who know what kind of over head there is calling a *.so from java ?

Any thoughts.
[Nexus One Android Development] pr0cl1v1ty:
this is completely and entirely true. although we have this ability to do ourselves but then again we wont have EA or Gameloft creating games just for XDA *i wish lol* some good iphone graphical games range from 50mb and up
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Hmm, at that frame rate you'd be seeing actual noticeable stuttering. I definitely haven't seen that with that triangle demo I made for ES 2.0. It seemed to be perfectly smooth, implying upwards of 20fps.

That aside, having it all in the JNI would likely be significantly faster, although you might run into some problems. For one, you don't have access to EGL from the JNI, so you don't have much of a way to handle things like swapping the buffers. Another possible problem(in that I'm not sure how/if it works) would be actual controls. If you don't give back control or don't pass any data between the java side and the jni, then you'd have to handle all input and sensors yourself in C, which as far as I've seen, isn't possible.

EDIT: Ahh, you're asking about frame rates for the basic san-angeles, not my little demo for ES 2.0 I threw together using that as a base, aren't you? Hmm, I hadn't actually bothered trying that demo before ripping it apart and putting my code, so I can't testify to what frame rate you should be seeing.
[Nexus One Android Development] d1mbu1b:
Thanks for the reply.

The all java NeHe tutorials have a decent frame rate. So I have to assume if the one per frame JNI calls are slowing it down.

I must be missing something simple.

like maybe wait() is being called in GLSurfaceView.GLThread.runGuarded()...

Here is my theory...

I figured i would modify my own GLSurfaceView.java

There exists a private EGLHelper class which has the bindings for EGLDisplay, EGLSurface, and EGLContext. Then just release contol via one time JNI call in the thread mGLThread.guardedRun(); not sure these binding objects can tranlate to the void pointers that eglSwapBuffers expects. (BIG IF). I found swap buffers in /system/lib/egl/libEGL_adreno.so and /system/lib/egl/libGLES_android.so

However the ndk include does not have a function prototype for it. thus trying to force the use of GLSurfaceView.

Since the render loop is in its own thread (GLThread) I THINK its coverred.

I think I can still take advantage of the Activity class and a JNI method(s) for passing UI data to the native code. This way I can still conform to the android "ideal" and still take advantage of the nice UI tools.

What a mess. I highly doubt khronos had any of this in mind.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
For the second-to-last bit, if I understand you correctly, wouldn't you have to deal with making everything thread safe then, and use semaphores/etc to make sure that you aren't reading the position/whatever variables for the display at the same time they're being altered by your control functions?

At any rate, this is all so complicated mainly because we're trying to use the ndk. In the straight sdk, all this stuff is fairly straight forward and runs at a decent rate, they just haven't implemented ES 2.0 in the SDK yet. I'm willing to deal with these kind of hassles though in order to be ahead of the curve like this.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Oh by the way, I'm gonna be holding off on development for a while. For some reason my debugger completely ate it last night and now whatever I try to debug crashes immediately with a SegFault. I'm still trying to pin down the issue but so far rebooting the phone, uninstalling the app before trying to install over it and debug, restarting my computer, and reinstalling Eclipse on my computer hasn't worked.
[Nexus One Android Development] d1mbu1b:
got my answer

turns out even when I hyjack the GLThread in the native code with a while (1) loop the frame rate is still 7 fps...

So I guess that the san-angeles demo is just slow go figure.

I wrapped the nativeRender call in app-android.c with a while (1) and added eglSwapBuffers at the end of the loop.

I compiled by adding the eglSwapBuffers prototypes and linking against a copy of n1:/system/lib/*GL*.so that I adb pulled from the device.

Hop this is worth while for somebody.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Sorry guys, still no updates on the graphics stuff. I still can't debug on my phone and have no idea why. At this point, I think my only choice is to try to back everything up and reinstall Ubuntu entirely. I freaking hate using eclipse in ubuntu, it seems like something is always going wrong with it(Installing Eclipse from the Add/Remove programs screen makes it completely borked, had to just download it from the website and even then had weird UI problems and now can't debug. On my netbook, neither way of installing will let me install any plugins) but there's not much of a choice when it comes to using the NDK, outside of trying to fight with cygwin. Might try Mint or some other distribution if Ubuntu keeps giving me problems.
[Nexus One Android Development] skysurfer27:
If you're running 9.10 Eclipse was affected when they changed stuff in the new version of GTK, you need to export GDK_NATIVE_WINDOWS=1 before starting eclipse.

Also, are you having trouble with adb not finding the device? I always have to adb kill-server then sudo adb start-server for it to pickup my device and any update wants to kill the server and fire it up as a non-root user again.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Interesting. That'd probably solve the UI problems. ADB-wise: no problems. It finds my Nexus One perfectly. I figured out all the kill-server/start-server stuff a while ago. The problem is that when I try to debug(and this all the sudden started happening about a week or 2 ago) I get some massive SegFault-like crash while the debugger tries to connect. A couple times, it even caused my phone to reboot entirely. This happens with all apps(including trying to use one of Google's sample apps) and nothing I've tried so far has fixed it. I even tried reverting my phone to stock firmware and doing a full data wipe and it still happens. I can't see any other explanation other than it's something on my computer's side and deleting/redownloading both the Android SDK and eclipse haven't solved it.
[Nexus One Android Development] skysurfer27:
Does logcat give any clues to what the phone is going through when the debugger connects? Also, do you know if those wipes cleared the Dalvik cache? I wonder if something stale in there could cause such an issue.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Ya, logcat gives a (very long) error message. Can't remember the contents that well but I think it was a segfault. Like I said, it only happens when it's trying to connect the debugger. I can just go in afterwards and run the same app that I was trying to debug and it runs perfectly. Can't remember where it occurred 'cause the stack trace went through like 50 different packages. Also, a wipe should erase the dalvik-cache(it clears the entire /data partition), but regardless, I tried doing so manually and it didn't solve the issue.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Hmm after reading the release notes for the latest cyanogen(beta 4), that problem with the debugger may have had to do with JIT in beta 3. I enabled it briefly before turning it off again, but from things I've heard earlier, it can cause problems even after being disabled. I'll try again tonight using beta 4. In case people are wondering why I'm still posting here, I'm going to try to get a texture loader header file written up and post it here along with my matrix functions, so we have a fully functioning OpenGL ES 2.0 implementation.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
I managed to get up and running and found my first real bug in the OpenGL ES 2.0 library. The info log always returns gibberish after you try to compile a shader, so we get no meaningful explanation of what error occurred. That'll make shader writing a heck of a lot harder for the time being.
[Nexus One Android Development] robert-qfh:
Uh that's not good at all. Any update on this? The only workaround that comes to my mind is using an iPhone or at least the iPhone emulator to write/debug your shaders, and hope they run on Android, too. I wonder if Google is going to release official ES 2.0 support at the GDC...
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Haven't managed to get any reasonable info out of the shader compiler yet, but I did manage to compile them(after a LOT of work). Here's hoping they release something at GDC for it.

At present time, I have my shaders for my game fully compiling and working. Unfortunately, I still get a black screen so something must be horribly wrong in my actual drawing code. That was kinda expected, though, since I haven't used ES 2.0 before.
[Nexus One Android Development] tmac12:
http://www.engadget.com/2010/03/08/android-ndk-hits-release-3-brings-opengl-es-2-0-access-to-devs/
[Nexus One Android Development] JHaste:
awesome! i cannot wait for some good games to start popping up!

(gets credit card ready)
[Nexus One Android Development] robert-qfh:
Finally! Looking forward to decent GLES2 games, too :-)

I installed the new NDK yesterday to try the new stuff. The hello-gl2 sample is a good starting point. In order to use GLES 2.0 some special setup needs to be done by the Java code.

Unfortunately, there are two caveats. First, no support in the emulator. What's really bad, though, is that there's still no shader compiler output except "compiled" or "not compiled". I broke the shader code in hello-gl2 and fixed a bug in their loadShader() function, but GL_INFO_LOG_LENGTH returns 0 for both broken vertex and broken fragment shaders. Output is "Could not compile shader, no info available" :-(

GLuint loadShader(GLenum shaderType, const char* pSource) {
GLuint shader = glCreateShader(shaderType);
if (shader) {
glShaderSource(shader, 1, &pSource, NULL);
glCompileShader(shader);
GLint compiled = 0;
glGetShaderiv(shader, GL_COMPILE_STATUS, &compiled);
if (!compiled) {
GLint infoLen = 0;
glGetShaderiv(shader, GL_INFO_LOG_LENGTH, &infoLen);
if (infoLen) {
char* buf = (char*) malloc(infoLen);
if (buf) {
glGetShaderInfoLog(shader, infoLen, NULL, buf);
LOGE("Could not compile shader %d:\n%s\n",
shaderType, buf);
free(buf);
}
} else {
LOGE("Could not compile shader, no info available\n");
}
glDeleteShader(shader);
shader = 0;
}
}
return shader;
}
[Nexus One Android Development] mr.r9:
@robert-qfh, so basically you are coding in the dark?
[Nexus One Android Development] robert-qfh:
Yep, that's right, no compiler output so you have to guess why your shaders don't compile. This won't be a big problem for people porting over stuff, e.g. from the iPhone, but for a platform to develop shaders on it is a show-stopper. I hope a future system update (or an emulator with GLES2 support) will include a GL library that tells you why it didn't compile. Maybe someone at GDC (Marcus?) can get more information about that...