GLES2 does not support glPush*/glPop*. Does anyone know if there is an implementation of a state stack for OpenGL ES 2.0? Any solution to my problem is welcome.
glPushAttrib/glPopAttrib managed fixed-function state that was not moved over from the older versions of OpenGL. Programmable shaders replaced all of the fixed-function functionality in GLES, and newer versions of OpenGL.
State is now something you manage yourself via inputs to shader programs.
If you need a quick solution, you may be interested in this library (Github repository). It only emulates small subset of OpenGL 1.x, glPush*/glPop* included. Note, that mentioned project is still very much WIP, so don't expect everything to work out of box.
Related
I am in the process of reading WebGL and going through some tutorials .
But I think I had to learn OpenGL explicitly in order to work with WebGL more efficiently.
But there are many versions of OpenGL and this wiki link shows that WebGL uses OpenGL 2.0 but the latest version of OpenGL is 4.5 .
Can anybody suggest how to know which version of OpenGL is supported through some script in WebGL ,if possible.
WebGL is based on the OpenGL ES 2.0 API, however, there are some limitations they have adopted for increased availability.
The APIs of (modern) OpenGL, OpenGL ES, and WebGL, while not the same, are all closely related. If you know one, the usage of the other two is quite similar. In fact, you may be able to reuse a large amount of code between the three. So, knowing OpenGL would certainly help you implement a WebGL application, however, learning WebGL first is also plausible.
WebGL is not based on OpenGL. It is based on OpenGL ES 2.0. The same OpenGL ES found on Android and iOS.
There's significant differences between OpenGL and OpenGL ES. While OpenGL ES is a subset of OpenGL it is missing the old deprecated fixed function pipeline that so many people continue to use and so many outdated tutorials (like Nehe GL, still teach)
What's the fixed function pipeline? Anything having to do with glVertex, glColor, glNormal, glLight, glPushMatrix, glPopMatrix, glMatrixMode, etc... in GLSL using any of the variables that access the fixed function data like gl_Vertex, gl_Normal, gl_Color, gl_MultiTexCoord, gl_FogCoord, gl_ModelViewMatrix and the various other matrices from the fixed function pipeline.
Those are all removed from OpenGL ES 2.0 and therefore don't exist in WebGL
WebGL is based on OpenGL-ES 2.0
I need to software render OpenGL in Windows and have already found about Mesa3D, which doesn't provide DLLs and I'm having some pain to build... Are there alternatives available?
That depends on what OpenGL version you wish to accelerate. Depending on your needs, there are some alternatives available. I've listed those I'm aware of below:
OpenGL 1.0 & 1.1
Windows (since Windows NT 3.5) actually includes an OpenGL software implementation to begin with. If you haven't installed any other software rasterizer, this ought to be your default implementation. The Microsoft software rasterizer supports either OpenGL 1.0 or 1.1, depending on your platform, but will not accelerate anything newer than that. If your desired OpenGL version is covered by 1.0 or 1.1 (however unlikely), the solution should be sufficient. I'm unsure as to what extent the default Windows OpenGL software implementation covers the OpenGL ES 1.x frameworks through its OpenGL 1.0 or 1.1 support.
OpenGL 1.4
Furthermore, in Windows Vista, Microsoft included an emulation layer which may translate OpenGL into Direct3D; thus supporting up-to OpenGL 1.4. Additionally, this should mean that Windows Vista (and up?) runtimes may accelerate most parts of OpenGL SC. I've never used this emulator myself, and was quite surprised to hear about it, but it may be of interest to someone having to run one of these old frameworks in a Windows environment.
Note that the standard Windows OpenGL software rasterizer (OpenGL 1.0 or 1.1) is also included in Windows Vista and above.
OpenGL ES 2.0
Additionally, there's the ANGLE project which accelerates WebGL and OpenGL ES 2.0 by translating OpenGL ES 2.0 invocations to DirectX 9 and 11. Their development notes also mention that an OpenGL ES 3.0 solution is in the works. Never having used ANGLE, I cannot offer a verdict.
OpenGL 3.1
In addition to those mentioned above, Mesa 3D (which supports up to OpenGL 3.1) feature three software implementations:
swrast
softpipe
llvmpipe
Since I know very little of swrast (the original Mesa project software rasterizer) and softpipe (a reference driver) I'll refrain from going into these. The third implementation, llvmpipe, and probably the one that may interest you the most, is a high-speed software implementation that uses multithreading and JIT compilation to speed up simulation with native- and SIMD instructions.
I have used Swiftshader from Transgaming for a production project before and I must say, it was brilliant. A tad costly, but brilliant.
As far as I've searched, the only other option is using WebGL software renderer, that as of today only Chrome supports. Direct3D has the reference driver (which is really unstable) and Swiftshader, which is good and expensive.
After some more headaches I managed to build Mesa3D for Windows, but only an old version which had still some support for it. At least, it has an awesome performance.
Recently I want to learn OpenGL ES. But I don't know which version should I learn.
I have tried OpenGL ES 2.0. You have to implement much functions that build-in OpenGL ES 1.0.
The Programmable Pipeline is trouble, despite it's powerful.
OpenGL ES 2.0 have been used in cocos2d 2.0.
Which version is widely in use?
Which one should I learn.
I'm a iOS developer.
As an iOS developer, you should probably allow yourself not to worry about devices on versions of the OS prior to iOS 5, meaning that you can really on Apple's GLKit to provide all the functionality that's in 1.1 but removed from 2.0. iOS device sales continue to grow exponentially and iOS 5 is available for devices from the 3GS onwards and so by the time you're up to speed you'll be losing very little in terms of potential audience.
GLKit supplies:
as many matrix stacks as you want (plus quaternions)
prepackaged shaders that match most of the ES 1.1 fixed functionality effects
standard bindings between OpenGL and UIKit (so you never need write your own UIView subclass for OpenGL again)
prebaked code for texture loading, synchronously and asynchronously
This is Apple's head documentation page for GLKit (and it's worth expanding the 'more'). iOS 5 and GLKit is quite new so external resources are still a little disorganised, but this one looks good enough.
Apple's intention is explicitly to allow someone who would otherwise stick with ES 1.1 because it does so much for you to get a working ES 2.0 implementation with very limited extra effort, with which they can then take advantage of the programmable pipeline in any way they see fit as they learn more about it. So I'd say that you should put your faith in Apple, take advantage of their code and learn ES 2.0 + GLKit right off the bat.
Is it possible and not too complicated to use OpenGL ES for OS X development. I have been writing Mac applications for three years now and I am ready to start learning about OpenGL, but I want use OpenGL ES because there is a lot of information about using it with Xcode and Objective-C and from some of the code samples I found it seems easier to learn than the full OpenGL.
Thanks!
OpenGL-ES 1.1 is a true subset of OpenGL-2, ES-2 is a subset of OpenGL-3, the main difference is, how the context is created and managed. However context creation and management happen outside of OpenGL actually. So as long as you stick to OpenGL-ES, minus extensions specific to ES (i.e. OES extensions) you can do with an ordinary OpenGL context of the right version.
There are OpenGL-ES compatibility profiles, but those just disable functionality, don't add new one.
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