I've been hankering to start porting a game I've been working on(originally was going to be for Zune HD but they haven't released the damn 3D SDK. Video of it running in windows is available on youtube, where my username is marcusmaximus04) to android but was hesitant due to the lack of OpenGL ES2.0 support in the Android SDK. However, looking through the file system on my nexus one, I spotted the file libGLESv2.so, which appears to be the shared object file for exactly this!
Obviously, I still can't use the normal SDK to use this, but in theory, one could use the NDK to use OpenGL ES 2.0 features(shaders, etc) through that shared object file.
The purpose of this post is three-fold. One I want to know if anyone has any background with using OpenGL through the NDK or knows of any tutorials for doing so(I'm not entirely sure how that would work...). Two, I wanted to bring this to the attention of all the devs out there who might be holding off from using ES 2.0 features. And three, I wanted to let everyone else know that such a thing is possible, just 'cause it's exciting.
At any rate, even if I can't find any tutorials I'll probably start plugging away at getting this to work and this should make for an exciting couple weeks/months.
Since we have this pretty well working(even on non-rooted phones) I'll post a sample apk. It doesn't look like much, but it does prove that we're using OpenGL ES 2.0(this will only work on the Nexus One). I'll also post the libGLESv2_adreno.so shared library in the same zip file. Enjoy .
From http://developer.android.com/guide/topics/graphics/opengl.html:
note that though Android does include some basic support for OpenGL ES 1.1, the support is not complete, and should not be relied upon at this time.
Click to expand...
Click to collapse
so official 2.0 support might be a bit off :/
kozm0naut said:
From http://developer.android.com/guide/topics/graphics/opengl.html:
so official 2.0 support might be a bit off :/
Click to expand...
Click to collapse
Possibly, but it does still support it in the NDK(really, this hardcore graphics stuff should be done in the NDK anyway). Even there it's not really official, but they aren't likely to change the API calls since those are already set in stone by khronos.
Hi Marcus,
to get started, grab the OpenGL ES 2.0 headers from www DOT khronos.org/registry/gles/ and copy the library file from your phone to the NDK installation dir (build/platforms/android-4/arch-arm/usr/lib/). Next you might inspect the libGLESv2.so with objdump to see what functions it provides:
build/prebuilt/linux-x86/arm-eabi-4.2.1/bin/arm-eabi-objdump -t libGLESv2.so
It should have the 2.0 functions like glCompileShader(), glCreateProgram(), etc.
Finally, add the following line to the Android.mk file in the jni/ directory of your Android project:
LOCAL_LDLIBS += -Lbuild/platforms/android-4/arch-arm/usr/lib -lGLESv2
If you're lucky, that should allow you to compile and link OpenGL ES 2.0 code. I cannot try this right now but will as soon as I get my Nexus One on monday
I haven't done any OpenGL ES coding with the NDK, but it should be straightforward if you've written OpenGL (ES) code before. This might be of use: code DOT google.com/p/glesquake/
robert-qfh said:
Hi Marcus,
to get started, grab the OpenGL ES 2.0 headers from www DOT khronos.org/registry/gles/ and copy the library file from your phone to the NDK installation dir (build/platforms/android-4/arch-arm/usr/lib/). Next you might inspect the libGLESv2.so with objdump to see what functions it provides:
build/prebuilt/linux-x86/arm-eabi-4.2.1/bin/arm-eabi-objdump -t libGLESv2.so
It should have the 2.0 functions like glCompileShader(), glCreateProgram(), etc.
Finally, add the following line to the Android.mk file in the jni/ directory of your Android project:
LOCAL_LDLIBS += -Lbuild/platforms/android-4/arch-arm/usr/lib -lGLESv2
If you're lucky, that should allow you to compile and link OpenGL ES 2.0 code. I cannot try this right now but will as soon as I get my Nexus One on monday
I haven't done any OpenGL ES coding with the NDK, but it should be straightforward if you've written OpenGL (ES) code before. This might be of use: code DOT google.com/p/glesquake/
Click to expand...
Click to collapse
Alright! Thanks for the help. I've done a lot of opengl work before and a little bit of opengl es when i had my g1 but haven't ever used the ndk, so that'll get me started.
EDIT: Sweet, I've dumped the list of functions available and it looks like all the appropriate shader functions are there. I'm attaching the full list output from my computer. I actually had to use arm-eabi-strings, since the objs one showed no objects. Regardless, it's looking good on the OpenGL ES2.0 front, and I've already looked into running opengl code from the NDK which is perfectly possible and ok.
ANOTHER EDIT: Haven't quite gotten it to build yet, but I got it to load gl2.h without any complaints. Now I just have a crapload of errors because the sample project I was using(from the ndk samples, san-angeles) was written for OpenGL ES 1.0 and all the things now done in shaders no longer exist(GL_LIGHTING, GL_MATERIAL, etc). Regardless, I'm considering this a success so far, since all that is expected.
YET ANOTHER EDIT: It runs! I'm not displaying anything yet(so it's not really a good test), but I got the shared library to build using OpenGL ES 2.0 and it runs on my phone. Gonna implement a simple program to display a triangle or something just to prove it works and will provide source code/binaries here(also, if anyone has a Droid or knows someone who does, it'd be great if we could test out to make sure this works on the Droid as well)
I just wanted to drop in and say I'm very interested in what y'all are doing I'm of very good at coding. All I know is Java but ill definantly be following yall and keep up the good work
Decided to post a reply, rather than just adding to that one post.
Well, I encountered a fairly large roadblock:
Code:
E/libEGL ( 3366): called unimplemented OpenGL ES API
That's what I see now every time I call one of the functions dealing with ES 2.0. I'm hoping there's another library I can use that'll make that go away, but we might not be as easy as I thought to do this.
That's bad news indeed. I was hoping that everything is in place and Google just didn't release a new NDK with ES 2.0 support yet, but if the libGLESv20.so is merely a stub, we're pretty much out of luck. I'd probably disassemble the file to see if there's actually some code besides "return unimplemented" in there, but even if there was, I'd have no idea on how to continue...
I'm wondering how they render the fancy rain drop effect on the wallpaper. Looks like a perfect fit for a 2.0 fragment shader, however there are a lot of other ways to create that effect.
robert-qfh said:
That's bad news indeed. I was hoping that everything is in place and Google just didn't release a new NDK with ES 2.0 support yet, but if the libGLESv20.so is merely a stub, we're pretty much out of luck. I'd probably disassemble the file to see if there's actually some code besides "return unimplemented" in there, but even if there was, I'd have no idea on how to continue...
I'm wondering how they render the fancy rain drop effect on the wallpaper. Looks like a perfect fit for a 2.0 fragment shader, however there are a lot of other ways to create that effect.
Click to expand...
Click to collapse
Well I managed to view the assembly code, but can't get it into any form that I can/want to read(I know how to read assembly but unless you spend hours with it, it's damn near impossible to decode anything. Plus, I haven't looked at ARM assembly before). Know of a good program to convert it into C?
At any rate, I'll attach the disassembler dump(ran it using arm-eabi-objdump with flags -DS). From looking at it briefly, all the implemented functions look like they might be stubs since they're pretty bare bones and have almost all the same instructions(with a slight modification to one single instruction). But it's hard to tell with assembly. Let me know if you can make anything of it. I had to attach the file in a .zip by the way because it was too big.
SUCCESS!!!! So, it looks like those functions were stubs. Google seems to have done it intentionally for whatever reason. They took the .so that actually worked(libGLESv2_adreno200.so) and shoved it under /system/lib/egl, which the ndk doesn't seem able to access(gives you a runtime error if you linked against it). However, If you just copy that file to /system/lib (yes, this requires root unfortunately) then you can use it. I successfully drew a triangle using shaders .
I'll try to get it to attach that xxx_adreno200.so file to the .apk so it can be used without messing around with such things(and work without root). If I can, then I'll throw it on here so everyone can see. Right now it's just a triangle, but tomorrow: the world.
EDIT: Alright, I attached the .apk(it's in the zip file, xda still doesn't allow posting .apks). I tried to attach the libGLESv2_adreno200.so library to it, so it wouldn't require moving the local one but it just wouldn't accept it. So, at least for the mean time, if you want to actually run that app without having it crash you'll have to do an adb remount and then the following in the terminal(or adb shell) as root:
Code:
cd /system/lib/egl
cp libGLESv2_adreno200.so ../
Once you do that, when you run the app it should display a yellowish triangle on a blue background(it was from the second tutorial from the OpenGL ES 2.0 sdk for PowerVX). Like I said, it's not much right now, but it is using custom shaders to display that triangle.
ANOTHER EDIT: I decided to change the test program a little. All I changed was the fragment and vertex shaders, which I made to change the color of the pixels based on where they are on the triangle. This should show(to those of you who know OpenGL) that it really is using custom shaders, since it's one triangle and it's clearly not using fixed-function pipeline shading .
Awesome work on reverse-engineering this! Keep us posted.
Indeed, keep at it Marcus! Very interested to see how this progresses.
Well done, Marcus! I'm glad you found that working library.
You should be able to embed the library search path in your own library by using the rpath directive while linking your program. See "man ld" for more information. You need to get the NDK to call the compiler like this:
gcc ... -Wl,-rpath=/system/lib/egl
That should allow you to use that library without copying it around, and therefore make it work on non-root phones as well.
I guess all you need to do is add the directive to the LOCAL_LDLIBS variable in Android.mk, or maybe it has LOCAL_LDFLAGS, which would be more appropriate.
robert-qfh said:
Well done, Marcus! I'm glad you found that working library.
You should be able to embed the library search path in your own library by using the rpath directive while linking your program. See "man ld" for more information. You need to get the NDK to call the compiler like this:
gcc ... -Wl,-rpath=/system/lib/egl
That should allow you to use that library without copying it around, and therefore make it work on non-root phones as well.
I guess all you need to do is add the directive to the LOCAL_LDLIBS variable in Android.mk, or maybe it has LOCAL_LDFLAGS, which would be more appropriate.
Click to expand...
Click to collapse
Ya, I tried adding it to LOCAL_LDLIBS, but that just seemed to make it use that path for the local library on my computer when building it. It still failed to find that library on my phone when I ran it. I'll try poking around a little more since that would obviously be ideal.
Alright. Are you sure you used rpath and not rpath-link?
BTW, there's a libGLESv2.so in the 2.1 emulator image. Did you try using that? I wonder if the emulator supports ES 2.0...
robert-qfh said:
Alright. Are you sure you used rpath and not rpath-link?
BTW, there's a libGLESv2.so in the 2.1 emulator image. Did you try using that? I wonder if the emulator supports ES 2.0...
Click to expand...
Click to collapse
I didn't touch either actually, just changed the name of the library and the path it had. I haven't done a lot of make files beyond the most basic operations so a little study might be necessary.
Haven't tried the emulator image one, but the one from the phone just had those stubs. It would be really strange if the emulator had the actual functionality and the phone didn't.
I think you're right that if there's hope then it lies in the makefile, so I'll keep looking into that.
EDIT: Just tried adding --rpath=/system/lib/egl everywhere I could possibly think of and all with no change.
Hmm I can't try this yet, but it looks like it uses the property java.library.path to determine where to look for shared libraries. Maybe I can have it look in /system/lib/egl too?
Ack, tried it, didn't do anything. Still can't find that library.
So ya, I'm giving up on this front for now. Google obviously has some of this ready but doesn't want us using it for now, so I'll just wait for them to give us access unless I get some new info. In the meantime, I'll continue the work I've already started on porting that game from the video I linked to. At least we now have the tools to test this stuff.
[email protected] said:
Hmm I can't try this yet, but it looks like it uses the property java.library.path to determine where to look for shared libraries. Maybe I can have it look in /system/lib/egl too?
Ack, tried it, didn't do anything. Still can't find that library.
So ya, I'm giving up on this front for now. Google obviously has some of this ready but doesn't want us using it for now, so I'll just wait for them to give us access unless I get some new info. In the meantime, I'll continue the work I've already started on porting that game from the video I linked to. At least we now have the tools to test this stuff.
Click to expand...
Click to collapse
thats depressing i was checking this thread like 10 times a day waiting for new info to popup lol call me obsessed but i respect your work
Yet another idea to try. On Linux you can specify the library search path using the environment variable LD_LIBRARY_PATH, e.g. if you run a program like this
LD_LIBRARY_PATH=/some/path /path/to/program
then the linker will search that path for libraries.
Maybe it's possible to set that variable from within the Java code, but before the JNI library is loaded:
static {
// Set environment variable LD_LIBRARY_PATH
System.loadLibrary("your_jni_lib");
}
Finally another idea, so we cannot link our library to the OpenGL ES library. But we could probably dlopen() it from within the JNI library and grab all the function pointers using dlsym(). I will get my Nexus One in a few hours, and ES 2.0 will be one of the first things I'm going to look into
EDIT: Marcus, would you mind posting the source code of your ES 2.0 triangle demo application? Basically all I need is the gl....() stuff. I haven't done too much Shader stuff so far, so that would save me a lot of time.
robert-qfh said:
Yet another idea to try. On Linux you can specify the library search path using the environment variable LD_LIBRARY_PATH, e.g. if you run a program like this
LD_LIBRARY_PATH=/some/path /path/to/program
then the linker will search that path for libraries.
Maybe it's possible to set that variable from within the Java code, but before the JNI library is loaded:
static {
// Set environment variable LD_LIBRARY_PATH
System.loadLibrary("your_jni_lib");
}
Finally another idea, so we cannot link our library to the OpenGL ES library. But we could probably dlopen() it from within the JNI library and grab all the function pointers using dlsym(). I will get my Nexus One in a few hours, and ES 2.0 will be one of the first things I'm going to look into
EDIT: Marcus, would you mind posting the source code of your ES 2.0 triangle demo application? Basically all I need is the gl....() stuff. I haven't done too much Shader stuff so far, so that would save me a lot of time.
Click to expand...
Click to collapse
Sure. I'll post it when I get home from work tonight. I don't have anything proprietary in there yet.
For the setting of the environment variable, from my understanding that's basically what System.SetProperty("java.library.path"... is supposed to do. But it still couldn't find the library and didn't seem to have any effect.
The dlopen bit might work. I was thinking of trying that but haven't had any time. I'm not really too sure on how these shared libraries are used, whether once they're open any other program can find and use them or whether the path to them has to be given explicitly at link time for the program that wants to use them and just generally having one loaded won't help.
EDIT: By the way, @pr0cl1v1ty: Don't worry, I'm not going to stop digging into ES 2.0 entirely. I'm just not going to be pushing as much for getting it to work on non-rooted phones. I've got bigger fish to fry.
Hey, I was just wondering:
Would the thunderbolt EVER be able to play xperia play apps (with a little hacking?)
How much more/less advanced is it than the play? If at all ?
is the processor/hardware architecture in general never going to be able to?
It all seems very.similar (me being a noob?)
I was wondering because this whole minecraft pocket edition is going to drive me insane on release. thanks!
Sent from my ADR6400L using XDA App
Nothing?
I recently found a sysdump for the xperia play in its forum on this site.
However, whenever I attempt to open any of the apk files, I get:
"There is a problem parsing the package."
It would be cool if we can crunch on this and get something to work
I am a fairly experienced android programmer, but not much of a hacker/know nothing framework wise (OS level)
Thinking about starting something in the development forum.
Maybe the .apks have a device check built into them so they only work on the Play?? If that's the case it should be possible to decompile thr apk, disable the device check, and recompile to make it work. However, I cannot speak to what kind of quality you would get trying to play them on the tbolt.
Sent from my HTC Thunderbolt
Yeah, I thought the same.
And they both have a qualcomm snapdragon with adreno graphics.
Maybe chainfire will amp up performance (if poor) on the tbolt and if you're not running sense you can run that wii controller adapter thing. (for a control pad)
Six months ago, I gave up on the latest version of ES and reinstalled the old version. About a month ago, I was invited to try the ES Beta. I was curious about what they might have changed in this newest version, so I said OK.
I have to say, in the Beta, the new interface looks a little crowded, but I don’t care that much about looks. What I really think is important is if an app is useful or not.
Every time I want to download a new file or transfer a file from my laptop to my phone, I can't immediately find it in the library. It really bothered me. I tried quite a few file-management apps, but nothing really worked the way I wanted it to. Until now. I found that the ES 4.1 Beta solved this file issue. Every single change about the number of files is displayed on the home screen, and the library shows which file was “Last opened” and which was the “Last created.”
ES move Encrypt and Compress to the home screen in the Beta. Former users may remember that ES had these two functions before, but if you wanted to find Encrypted or Compressed files, you had to press and hold on files before doing anything. In this Beta version, you can manage all these files right on the home screen.
I’m always transferring files with my co-workers. Due to security concerns, we always encrypt those files first. The ES Beta encrypts files by masking the file names without zipping them. It also supports encrypting zip files. When the file is too large, I’ll choose this way. Unlike other file management apps, ES is more stable when encrypting files, decreasing the possibility of damaging the file. It’s the best app for your zip and rar archives.
Logger displays newly created files on the device. Actually, I don’t find this essential for daily use, but I found it could monitor auto-created files. Now, I check logger every day, just in case some files downloaded themselves. It’s very useful for people who are used to deleting these files themselves. It will save some space, but logger loads slower at first start-up. I found that after unlocking Real-Time Observer, it would load in less than 2 seconds.
This new version doesn’t support theme changing yet. Classic themes and Holo themes can’t be used, either. I left feedback for ES about this. They promised new themes will be coming soon, and I’m sure they won't let their users down.
I have to admit they f*cked it up a bit.