I am trying to get an OpenGL ES demo app to build on Windows with Mesa. I'm confused about the EGL side of things.
When my project links, it can't find eglTerminate() (and other EGL functions).
I've checked for a libEGL.lib file but I don't have one. Do I have to build the src\egl code into a library as well?
Unless something changed recently, I'm not even sure how you got an ES DLL in the first place.
Related
Currently I'm doing some GLSL-stuff and to my surprise I cannot find a reasonable IDE for this (MacOS). Nothing to fancy, but just a way to change the code and see the results. I know of the Shadertoy-website, but I'm more interested in an offline solution.
So I came across the built-in OpenGL Shader Builder. According to Wikipedia, this is deprecated and superseded by GLSLEditorSample, which should still be available as an example project for XCode (of which I have version 7.3.1 installed). However, I basically cannot find anything about this, online nor on my computer. Therefor my question: Is this still relevant? If so, where is it located?
PS: if you know of any other GLSL IDEs, I'm open to that as well
Here they explain how to setup OpenGL on a MacOS on Xcode:
https://www.youtube.com/watch?v=Tz0dq2krCW8&list=PLRtjMdoYXLf6zUMDJVRZYV-6g6n62vet8
I'm building an application with OpenGL ES 2.0 and SDL2 for Android. Is SDL_GL_GetProcAddress working with OpenGL ES 2.0 on Android? Also i know OpenGL ES 2.0 is a subset of OpenGL, so with this method can it run on desktop systems too?
From a quick browse of the SDL repository it should be.
SDL_video.c defines the implementation of SDL_GL_GetProcAddress simply to check that you've started OpenGL and then to call _this->GL_GetProcAddress, where _this is a global instance of the video driver.
SDL_androidvideo.c sets its GL_GetProcAddress to be Android_GLES_GetProcAddress, which is a preprocessor substitution for SDL_EGL_GetProcAddress.
So, so far: if you call SDL_GL_GetProcAddress, you'll get through to SDL_EGL_GetProcAddress.
SDL_egl.c implements SDL_EGL_GetProcAddress but declines to call eglGetProcAddress on Android. This looks like it's probably an error — the reason given is this bug but the status for that bug switched to 'Released' in June 2013, which I believe means that this has been fixed in Android for more than three years.
That aside, the fallback is to use SDL_LoadFunction, first with the direct function name, then with it proceeded by an underscore provided it's short enough to fit into the statically-declared buffer. Which this one is.
(so, caveat: SDL_GL_GetProcAddress is definitely not thread-safe, even if you've taken appropriate share group steps to use multiple GL contexts, but if you're writing an SDL program you probably don't care)
Android should be using the dlopen version of SDL_sysloadso so it looks like SDL_LoadFunction is implemented directly as a call to dlsym. Which has no issues that I'm aware of under Android.
So, in summary: yes, that call should work. It'll use the platform-specific dynamic library loader rather than the EGL call though it probably doesn't need to, but that's just an implementation detail.
I need some OpenGL extensions (ANDROID_extension_pack_es31a) on my Google Tango. glGetString(GL_EXTENSIONS) lists all the extensions I need, so I'm sure the hardware supports it. While searching for a solution it seems that these extensions are available with API-21 (not quite sure about that).
My device still runs API-19 and I'm able to find out if/how I can update it.
I'm also not able to find a way to use the extensions in API-19.
Do you have any suggestions on how to solve any of problems?
I should mention, that I'm using the NDK for this project.
Thanks
Kai
If you want to use anything opengl Es 3.1, it have to be API-21.
There is not way you use them on API-19 which is current Project tango at.
This might be a trivial question, but here is this issue I wonder about cocos2d-x in general. I've read somewhere cocos2d and cocos2dx are based on OpenGL ES (2.0 i guess?). And also from the creators of cocos2dx that OpenGL ES 2.0 is not yet enabled in it.
This sounds to me like someone saying Obj-C is written based on C, but C is not yet enables in Obj-C!
is there anyway (coz I couldn't find any nice tutorial on the net anywhere) to integrate OpenGL ES 1.0/2.0 in cocos2dx?
If not, write OpenGL ES 2.0 in Obj-C and integrate in cocos2dx, .cpp files. (use classes etc, maybe wrapping objects from Obj-C, but how would I wrap a large class inherited from UIView [to alter draw() method] to be able to use in .cpp file in my cocos2dx project?)
Very much appreciate your help in advance,
P.S. I have been like a sitting duck for the past month, thanks to this issue.
The link you referred to in a comment is one year older. Check this one out instead: http://www.cocos2d-x.org/projects/cocos2d-x/wiki/Download
OpenGL ES 2.0 is now supported now in cocos2dX.
Cocos2d-x is written in C++ and OpenGL ES 1.1/2.0, so OpenGL ES is already supported (integrated).
I thought this should be easy, but... geesh! A vendor gave me a fairly simple demo program meant to showcase some trivial icon animations. The target platform is an embedded system (MX51) with accelerated OpenGL ES 2.0/OpenVG and EGL support.
Unfortunately, the demo also has an annoying dependency on a few Qt utility classes (e.g., QImage). If not for this dependency, I would compile/run the thing on the target. But I don't relish the thought of cross-compiling Qt just to run this little demo---even if there were enough room for it on the embedded board.
I hoped I might be able to run the app on a standard(ish) Ubuntu 10.04 VM, and started following these directions to make it happen. And I actually managed---like, 10 hours later---to compile everything and get a runnable binary of the demo program. However, when I run it, I see the following error:
eglCreateWindowSurface: egl error "EGL_BAD_CONFIG" (0x3005)
Sigh. Not what I wanted to see after all that effort. This seems way more difficult than it should be.
Is the embedded GL landscape really such a ghetto that I have to run even trivial programs on the target using some vendor-supplied BSP? Judging from the lack of responses to this guy's question, I'm thinking the answer might be yes. But I don't even care about acceleration (yet). I just want to run the stupidest of OpenGL ES 2/OpenVG programs on a desktop PC and get an idea of how it looks. (It doesn't matter to me whether the PC is running Linux or Windows.) How do people do this sort of thing?
There are several OpenGL ES 2.0 emulators, such as:
For ARM Mali GPUs
For PowerVR GPUs
Also very recently, AMD has posted drivers that expose OpenGL ES 2.0 on desktop.
More recently, OpenGL 4.1 exposes the GL_ARB_ES2_compatibility extension, which makes OpenGL 4.1 drivers GL ES 2.0 compatible.
For OpenVG, you can use AmanithVG GLE.
Qualcomm's OpenGL ES emulator includes OpenVG support. You can download it from http://developer.qualcomm.com