I have purchased a graphics card which supports OpenGL 4.2. But I want to develop an application which should support OpenGL 2.0
Does my card will support OpenGL 2.0 apps(Backward compatibility)??
Then how to ensure backwards-compatibility
I have planned to use GLUT/GLFW C++ libraries.
https://developer.nvidia.com/opengl-driver - please read about compatibility and that no 'old' functionality will be removed from the drivers.
In general you can create your application in two modes:
Core: This is modern OpenGL, no fixed pipeline functionality. In freeGlut you can use glutInitContextFlags (GLUT_CORE_PROFILE); and glutInitContextVersion (4, 2); to use core opengl 4.2
Compatibility: all functionalities from OpenGL 1.1 up to 4.2 (in your case) are supported and all those features can be used in your code. By default apps use this profile, or you can create it via glutInitContextFlags (GLUT_COMPATIBILITY_PROFILE );
Your graphic card will have the backward compatibility with OpenGl 2.0 app. You do not need to do anything special
Related
Using llvm you can write a Programm which runs on PC, Mobile and since WebAssembly even in your Webbrowser. But for an Example Android uses Opengl-ES. Is there any opengl version which can be used on each of these platforms?
There is no single version of OpenGL that runs everywhere, but OpenGL ES 2.0 is pretty close to the lowest common denominator.
WebGL 1.0 is very similar to OpenGL ES 2.0. WebGL 2.0 is a subset of OpenGL ES 3.0, with various restrictions which are required for security.
On desktop systems, there is usually a way to create an OpenGL ES 2.0-compatible context and use the exact same API as on Android. Regular desktop OpenGL has a few incompatibilities with OpenGL ES, see for example this page:
https://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences
Mobile devices almost universally support OpenGL ES 2.0, and most flagship phones support OpenGL ES 3.2. The current distribution of support for OpenGL ES on Android phones is at the bottom of this page: https://developer.android.com/about/dashboards/
In other word, is there any GPU that does not support OpenGL, and instead support other graphic rendering libraries like DirectX, OpenCl.
"GPU support of OpenGL" is not uniquely defined. It takes much more than hardware to make OpenGL work. Notably, OS driver infrastructure, and driver itself.
Therefore, it is possible to have a GPU that is capable of all OpenGL features, but have no OpenGL software implementation (either not exists, not installed etc.). Ex.: because of marketing reasons Microsoft does not support OpenGL on XBox. Same thing with Windows: often there is only basic OpenGL available with default Windows graphics drivers. It could be easily fixed by installing vendor driver, but most users don't bother.
And other way around, there are GPUs that are not capable of running some or all of the OpenGL features in hardware. Those features could be implemented in software. Ex.: First Android OS versions had software implementations of OpenGL ES in case phone didn't have dedicated GPU or if GPU was not fully capable of OpenGL ES.
Also, there are platforms that do not support OpenGL or DirectX and use their own APIs. Ex.: Sony use custom API for their Playstations.
At this day and age, no, you'll not find a GPU that won't support some version of OpenGL, with the possible exception of some super-specialised chips - but those won't support DirectX either.
Is it possible to use Libgdx for a desktop development only and access newer versions of Opengl from Libgdx abstraction? I mean, if you want to develop mobile apps you will have to use a some verison of Opengl ES, which does not support lot of things like classic Opengl does (e.g. drawing wireframes, etc.).
Lets say I don't want to use Opengl ES but normal Opengl, version 4+ in these days, and fully use its features for oa desktop development. Does Libgdx have support for this?
On the desktop, libGDX is built on top of LWJGL, which at of the time of this answer supports up to OpenGL version 4.5.
So if you're using libGDX on the desktop, then you can simply access the LWJGL calls directly. This will break your build for mobile or web deployment though.
I'm working on some cross-platform desktop application with heavy 2-D graphics. I use OpenGL 2.0 specification because I need vertex shaders. I like 3.2+ core API because of it's simplicity and power. I think that 3.2+ core could be a choice for the future. But I'm afraid that nowadays this functionality may not be available on some platforms (I mean old graphic cards and lack (?) of modern Linux drivers). Maybe, I should use OpenGL ES 2.0 -like API for easy future porting.
What's the state of affairs with 3.2+ core, cards and linux driveres?
Older Intel chips only support OpenGL 1.5. The later chips (since about two years ago) have 2.1 but that performs worse than 1.5. Sandy Bridge claims to support "OpenGL 3" without specifying whether it is capable of doing 3.3 (as Damon suggests) but Linux drivers only do 2.1 for now. All remotely recent Radeons and Nvidia hardware with closed-source drivers support 3.3 (geometry shaders) and the 400-500 series support 4.1 (tesselation shaders).
Therefore, the versions you want to aim for are 1.5 (if you care about pre-Sandy-Bridge Intel crap), 2.1 (for pretty much all hardware), 3.3 (for decent hardware & closed-source drivers) or 4.1 (bleeding edge).
I have vertex and fragment shaders written with #version 120 and geometry shaders written in #version 330, to make fallback on old hardware easier.
You can stay on OpenGL ES 2.0. Even if ES mean Embed, it's a good approach because it remove all the fixed functions (glBegin, etc...): you are using a subset of OpenGL 2.x. So if you write your software by thinking only OpenGL ES 2.0, it will be fast and work on the majority.
In real, OpenGL ES 2.0 and desktop GL might have some difference, but i don't think it will be something you will use. If the extension GL_ARB_ES2_compatibility is supported, you have a "desktop" card that support the complete embed subset. (4 func and some const.)
Now, the real question is how many years of hardware do you want to support ? They are still lot of very old hardware that have very poor gl support. Best would be to support the less-old (OpenGL 2.0 is already old) :)
I would personally go for OpenGL 3.3, optionally with a fallback for 3.2 plus extensions (which is basically the same). It is the most convenient way of using OpenGL 3.x, and widely supported.
Targetting 3.1 or 3.0 is not really worth it any more, except if you really want to run on sandy bridge (which, for some obscure reason only supports 3.0 although the hardware is very well capable of doing 3.3). Also 3.1 and 3.0 have very considerable changes in shader code, which in my opinion are a maintenance nightmare if you want to support many versions (no such problem with 3.2 and 3.3).
Every hardware that supports 3.2 can also support 3.3, the only hindrance may be that IHVs don't provide a recent driver or a user may be too lazy to update. Therefore you cannot assume "3.3 works everywhere". The older drivers will usually have the same functionality via ARB extensions anyway, though.
Mac OS X doesn't support GL-3 context at the moment. This summer may change the situation, but I would recommend to stick with GL-2 plus extensions nevertheless.
Depends on your target market's average machine. Although to be honest, OpenGL 3.2+ is pretty ubiquitous these days.
Since I'm not familiar with iPhone development I'd like to know whether it is possible to use OpenGL ES1.0 on the iPhone 3gs rather than 2.0.
I'd like to share a code base across different mobile platforms and not having to deal with the programmable pipeline from OGLES 2.0 could speed up an initial build.
Update -- I'm not used to working with OpenGL Es, but is there a always complete backward compatibility or do phones sometimes only support the latest version, eg 2.0
Thanks
Yes, you can. Simply call the OpenGL ES 1.0 APIs. The hardware is a full 2.0 device, but the software/driver can implement an OpenGL 1.x pipeline for you.