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.
Related
I am trying to make use of some ES 3.1 features, and it's unclear if this is supported:
I notice that there is an OpenGL ES 3.1 header in the emscripten repository which defines some of the functions I'm looking for, and I can include them successfully in my project. However, they are not available when I try to link:
error: undefined symbol: glDispatchCompute (referenced by top-level compiled C/C++ code)
warning: _glDispatchCompute may need to be added to EXPORTED_FUNCTIONS if it arrives from a system library
The documentation says that OpenGL ES3 is supported if I specify -s FULL_ES3=1 (which I am doing).
Since there are headers for it, is this functionality available? If so, how do I enable support for it? (Does it require manually loading extensions or enabling experimental support in emscripten, for example?)
First thing to realize, is that decent Browsers currently implement only WebGL 1.0 (based on OpenGL ES 2.0) and WebGL 2.0 (based on OpenGL ES 3.0). So that Emscripten SDK may implement only features presented by WebGL 2.0 + extensions, and, unfortunately, Compute Shaders are not presented in any way in WebGL (and there are no more plans to add this functionality in future).
By the way, WebGL 2.0 support has been added to Safari 15 (iOS 15) only this (2021) year, so that even OpenGL ES 2.0 will not work on all devices.
I notice that there is an OpenGL ES 3.1 header in the emscripten
The extra <GLES3\gl3*.h> headers are there not because Emscripten implements all of them, but because this is a common way to distribute OpenGL ES 3.x headers that existing applications may rely on to conditionally load / use OpenGL ES 3.x functions at runtime, when they available.
The documentation says that OpenGL ES3 is supported if I specify -s FULL_ES3=1 (which I am doing).
I think that documentation is more or less clear about what FULL_ES3=1 adds:
To enable OpenGL ES 3.0 emulation, specify the emcc option -s FULL_ES3=1 when linking the final executable (.js/.html) of the project.
This adds emulation for mapping memory blocks to client side memory.
There is no word about OpenGL ES 3.1 here, nor a reason to expect a wonder from Emscripten, as I can barely imagine a reasonable hardware-accelerated way to emulate things like Compute Shaders on top of OpenGL ES 3.0. And software emulation would be certainly of no use for most applications.
WebGPU 1.0 that promised to appear mid '2022, is more capable than WebGL 2.0. So that WebGPU developers already see that at one time native WebGL 2.0 implementation in the Browsers could be replaced by a WebAssembly module implementing this legacy API on top of WebGPU - but in some very distant future. The same could also bring OpenGL ES 3.1/3.2 features to Emscripten SDK - at least theoretically, if somebody will be still interested to work on this.
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've read places that Windows Phone 8 will not support OpenGL, and I'm unable to find anything useful in the SDK.
So am I or will I ever be able to use OpenGL (ES) in my Windows Phone 8 game? I have a game I would like not to rewrite completely to DirectX when porting.
Please cite good sources, the only thing I've found are speculations and blog posts with little to no information.
OpenGL isn't supported on WP8, but Direct 3D feature level 9_3 is supported. If you're looking to port over a game from OpenGL ES over to D3D have a look at the Angle Project. Angle Project helps bridge the gap between OpenGL ES 2.0 and D3D 9. It doesn't have WP8 targeting just yet and you'll have issues with runtime compile shaders not being supported on WP8, but Angle project is still a good first step.
Either way, for games portability with other platforms it's really best if you work with a middleware gaming framework such as MonoGame, Unity, Cocos2D, Havok, Marmalade, SharpDX, Ogre, Autodesk Scaleform or others. These engines will mostly handle cross platform support for you within their own framework (each with it's own limitations on code and assets portability).
If you already have an existing OpenGL game you want to port over to WP8, than Angle project if your best bet going forward. If you're just starting out creating a cross-platform portable game than choosing a gaming middleware framework that seems right for your game's needs is the way to go.
Marmalade does let you write OpenGL ES 2.0 code and make it work in Windows phone 8 without making you do anything
Check this for more details:
http://www.madewithmarmalade.com/windows-phone-8
Even if Windows Phone 8 supported OpenGL (which it doesn't), it would support OpenGL ES, not destkop OpenGL. Since it's for embedded platforms.
So that's no twice.
Gideros uses OpenGL and targets Windows RT/Phone graphics by means of a lightweight DX wrapper.
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.
I am trying to figure out the relationship between CGL and OpenGL on Mac platform.
More specifically about the context. Do they share context? If yes, how? Please give me a link to some related examples.
If no, then are there two contexts working in Core Animation applications which make use of OpenGL?
I am very confused by the use of OpenGL by Mac. Can somebody clarify?
CGL sets up device specific contexts suitable for OpenGL to render to. Compare to wgl and xgl on Windows and X respectively. CGL understands how to query the graphics hardware for its pixel format, and then how to set up and configure a context (e.g. double-buffered or single-buffered, what resolution depth, stencil, accumulation buffer, etc). But it doesn't provide functions to draw in that context. Once you have created the context with CGL, you make it current, and then you can call OpenGL to render in that context.
In Core Graphics (do not confuse it with CGL), both context initialization and drawing into the context are handled by the same framework. But because OpenGL is an open standard and designed to be cross-platform, the rendering functionality and the device context functionality have been abstracted into separate frameworks.
CGL is the low-level interface to OpenGL on a Mac. You probably don't want to be using it if you are writing an OpenGL Mac app. I am currently in the process of creating a intuitive OpenGL Mac application template for XCode 4, but in the mean time you can look at https://github.com/mk12/Pong-Ultimate, a pong clone I made using OpenGL. It uses NSOpenGL, a higher-level Cocoa interface to OpenGL.
You may also find the Apple docs helpful: http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html.