I set up OpenGl with DevC++ following a tutorial and everything works. I've looked into the main OpenGl project page (https://www.opengl.org/) but I can't find an official repository where I can download the packages that I need (I've found .zip but I can't understand the correct files that I need :(). I have seen many tutorials but they use unofficial repositories and they install packages in so many different ways even for the same IDE! :(. Is there an official repository? What files do I need? Is there a unique way to install OpenGL and if not could you tell me the most important steps of the installation ?
Is there a unique way to install OpenGL and if not could you tell me the most important steps of the installation?
Install drivers for your graphics card with OpenGL support. Done!
OpenGL is different than Direct3D or Mantle (or, soon to come, Vulkan): Back in 1996 OpenGL-1.1 was included into the Windows 32 bit platform ABI (Application Binary Interface). That means that for every Windows version after "Windows 95B" and "Windows NT 4.0" programs are assured for OpenGL-1.1 to be available.
Being part of the platform ABI has the nice side effect and consequence, that everything that's required for OpenGL development must be included in every compiler package that targets the Windows 32 bit (and by heritage the 64 bit) platform.
However the ABI covers only OpenGL-1.1. For everything that comes after the so called "extension mechanism" is provided. By using the extension mechanism programs can determine at runtime, which OpenGL capabilities (beyond v1.1) are available and load them. No extra libraries or SDKs are required for this!
Yet, since the process of enumerating available OpenGL capabilities and loading them is so tedious, a number of helper libraries exists that alleviate one from this annoying task.
you probably have OpenGL in your system as a part of your graphic card... You can see how to have a project running for different OS by taking a look at the OpenGL superbible:
https://sgar91.files.wordpress.com/2010/11/opengl-superbible-comprehensive-tutorial-and-reference-5th-edition-2010.pdf
Page 48 starts to talk about how to have a program running with OpenGL
Related
I am a new to programming and also to this platform so i apologize if
my question is not proper or seems stupid but i need help .None of the
resources on internet have been useful to me . If possible please
provide step by step instrction to set up mac for graphics
programming. thank you in advance.
I am a new to programming and i am trying to learn graphics programming .Till now i write c/c++ code in a text editor and compile and execute them to see the output in shell . I searched the web for setting up mac for opengl projects but none of them come close to clearing my doubts . Here are the doubts/questions :
my computer: macOS-Mojave :macbook pro mid 2012 (intel hd graphics 4000) supports openGL 4.1 according to apple website
1. do i have to download some files to use openGL ? or is it just a an api implemented by the computer hardware manufacturer(here apple in my case ).
2. according to recent news apple deprecated openGL. And i don't know which version of openGL is on my macbook . is there a way to find out ?None of the answers listed have worked for me.
3.Can i compile openGL code through terminal like i have been doing till now or do i have to use xcode ?
1. do i have to download some files to use openGL?
So far, not yet. Everything required ships with the compilers by default. You just add -framework OpenGL to your compiler invocations and are good to go.
2. according to recent news apple deprecated OpenGL. And i don't know which version of openGL is on my macbook. is there a way to find out? None of the answers listed have worked for me.
You're mixing two different concepts here:
The deprecation of OpenGL in the macOS platform means, that OpenGL will disappear from that OS altogether, irrespective of what OpenGL version actually is supported. Eventually you'll have to either move to Metal, or use some wrapper like MoltenGL (which implements OpenGL on top of Metal) or MoltenVK (which implements Vulkan on top of Metal).
With macOS the highest OpenGL version supported is determined entirely by the version of macOS installed. That is different from other OS, where a mere driver update may give you a higher OpenGL version, as long as the installed graphics hardware meets the requirements of that higher OpenGL version.
3. Can i compile openGL code through terminal like i have been doing till now or do i have to use xcode?
Yes. And there's no difference between compiling from the command line, and through Xcode, because Xcode is just doing the very same command calls as you'd do through the terminal.
I have just upgraded my project to use Qt 5.7, on Mac I am able to load the html pages using Qt Webengine but on Window 7, the pages are not displayed, instead a black screen is shown.
I have also compiled simple browser example and it too only shows a black screen.
I am using the visual studio 2013 build of Qt 5.7
Does anyone know why it is not displaying the pages.
Does Qt 5.7 need any third party libraries for it render correctly on Windows.
We had a similar problem, whenever we started an application with a QWebEngineView it would only show a black screen or even crash on another machine. The problems occured due to wrong versions of api-ms-*.dlls and d3dcompiler_47.dll we had packaged with our app.
We found the correct versions on our developer machine with installed Windows SDK under "C:\Program Files (x86)\Windows Kits\10\Redist".
On a side note: We found that deployement of QWebEngine under windows is quite a hassle.. you also need to include "qtwebengine_locales" from qtbase\translations and "resources" from qtbase as well as "QtWebEngineProcess.exe" from qtbase\bin.
A thing that helped tracking down the problem, was putting "CONFIG += console" in the pro-file. That way the console output with relevant error information is shown on deployement targets.
With help of this comment from peppe
One can use temporary workaround with graphic drivers not supporting DirectX11 but supporting DirectX9
As said here
https://doc.qt.io/qt-5/windows-requirements.html#dynamically-loading-graphics-drivers
Graphics Drivers
For Qt Quick 2 to work, a graphics driver that provides OpenGL 2.1 or higher is required. The default driver from Windows is OpenGL 1.1. Qt includes a version of the ANGLE project which is included from the Windows Qt installers. ANGLE implements the OpenGL ES 2.0 API on top of DirectX 11 or DirectX 9. ANGLE requires that the DirectX SDK is installed when building Qt.
ANGLE chooses the render backend depending on availability. DirectX 11 is usually preferable. However, some graphics cards may not fully support it. For these cases, the environment variable QT_ANGLE_PLATFORM (introduced in Qt 5.4) can be used to control the render backend. Possible values are d3d11, d3d9 and warp.
So this may help
set QT_ANGLE_PLATFORM=d3d9
Or use mesa with
https://www.mesa3d.org/llvmpipe.html
Qt::AA_UseSoftwareOpenGL is special in the sense that it will try to load an OpenGL implementation with a non-standard name. The default name is opengl32sw.dll. This allows shipping a software-only OpenGL implementation, for example a build of Mesa with llvmpipe, under this name. If necessary, the filename can be overridden by setting the QT_OPENGL_DLL environment variable.
Edit 1:
One can use fallback method for one-time login to Dropbox Windows client ( made with QT framework ) for example
Dynamically Loading Graphics Drivers
In addition to the build time configuration, Qt supports choosing and loading the OpenGL implementation at runtime. To use this mode, pass -opengl dynamic to the configure script.
Note: As of Qt 5.5 this is the configuration used by the official, pre-built binary packages of Qt. It is strongly recommended to use it also in custom builds, especially for Qt binaries that are deployed alongside applications.
...
This configuration is the most flexible because no dependencies or assumptions are hardcoded about the OpenGL implementation during build time. It allows robust application deployment. When a given environment fails to provide a proper OpenGL 2.0 implementation, it will fall back automatically to ANGLE. This fallback will be completely transparent to the application, and will allow Qt Quick or other OpenGL code to function by translating to Direct3D. Such a fallback could, for example, take place on a Windows 7 PC with no additional graphics drivers installed. On other machines, where there is sufficient OpenGL support, the normal desktop OpenGL drivers will be used. Additionally, pure software-based OpenGL implementations may be available as additional fallbacks in the future, allowing running Qt Quick applications without a GPU.
When configured with -opengl dynamic, neither Qt nor the applications built using qmake will link to the opengl32 (standard desktop OpenGL) or QtANGLE libraries. Instead, the appropriate library is chosen at runtime. By default, Qt will determine whether the system's opengl32.dll provides OpenGL 2 functions. If these are present, opengl32.dll is used, otherwise the ANGLE libraries (libEGL.dll and libGLESv2.dll) will be used. In case the ANGLE libraries are missing or initialization fails for some reason, an additional fallback is attempted by trying to load opengl32sw.dll. See below for details.
Such a fallback could, for example, take place on a Windows 7 PC with
no additional graphics drivers installed.
To emulate this conditions one can use RDP session with mandatory 8 bpp to Windows machine
I'm a bit confused about when exactly I need to use an OpenGL function loader like GLEW. In general, it seems like you first obtain a window and valid OpenGL context and then attempt to load functions.
Sometimes these functions are referred to as extensions, sometimes they are called core functions as well. It seems like what's loaded and classified as 'core' and 'extension' is platform dependent. Are the functions that are loaded in addition to some base set?
Do you need to load functions in the same way on OpenGL ES platforms as well? Taking a quick look at GLEW, I don't see any explicit support for Open GL ES. Other GL function loader libs do explicitly mention support specifically for ES however (like https://github.com/Dav1dde/glad)
OpenGL functions (core or extension) must be loaded at runtime, dynamically, whenever the function in question is not part of the platforms original OpenGL ABI (application binary interface).
For Windows the ABI covers is OpenGL-1.1
For Linux the ABI covers OpenGL-1.2 (there's no official OpenGL ABI for other *nixes, but they usually require OpenGL-1.2 as well)
For MacOS X the OpenGL version available and with it the ABI is defined by the OS version.
This leads to the following rules:
In Windows you're going to need a function loader for pretty much everything, except single textured, shaderless, fixed function drawing; it may be possible to load further functionality, but this is not a given.
In Linux you're going to need a function loader for pretty much everything, except basic multitextured with just the basic texenv modes, shaderless, fixed function drawing; it may be possible to load further functionality, but this is not a given.
In MacOS X you don't need a function loader at all, but the OpenGL features you can use are strictly determined by the OS version, either you have it, or you don't.
The difference between core OpenGL functions and extensions is, that core functions are found in the OpenGL specification, while extensions are functionality that may or may be not available in addition to what the OpenGL version available provides.
Both extensions and newer version core functions are loaded through the same mechanism.
datenwolf's answer is great, but I wanted to clarify something you said in the first bullet point of your question.
Core and extension status is not platform-dependent or even mutually exclusive.
Core means that some feature was introduced in a certain version of OpenGL. There are core functions, which are things that are guaranteed to exist in version X.Y and there are even core extensions, which are extensions that were introduced alongside version X.Y. Core extensions provide the same functions, types, enums, etc. as the core feature only in an extension form that does not require a specific version.
Framebuffer Objects went core in OpenGL 3.0, and are slightly less restrictive than the EXT extension (GL_EXT_framebuffer_object) that predates OpenGL 3.0. However, it is not necessary to have an OpenGL 3.0 implementation to have access to the core version of FBOs - an OpenGL 2.1 implementation might offer the core functionality.
In the extension specification for GL_ARB_framebuffer_object, you will find:
Issues
(8) Why don't the new tokens and entry points in this extension have
"ARB" suffixes like other ARB extensions?
RESOLVED: Unlike most ARB extensions, this is a strict subset of
functionality already approved in OpenGL 3.0. This extension
exists only to support that functionality on older hardware that
cannot implement a full OpenGL 3.0 driver. Since there are no
possible behavior changes between the ARB extension and core
features, source code compatibility is improved by not using
suffixes on the extension.
That is the first mention of a core extension that I can recall, but it is not the last. Since then many ARB extensions have been created that "backport" (if you will) core functionality from a higher version.
Here is some sample output gathered by parsing gl.xml for another core extension:
>> Command: void glBufferStorage (GLenum target, GLsizeiptr size, const void *
data, GLbitfield flags)
* Provided by GL_ARB_buffer_storage (gl|glcore)
* Core in GL_VERSION_4_4 ( gl 4.4)
It is core in 4.4 (guaranteed to exist in a 4.4 implementation), but because the extension that provides it is glcore, this core function may be available in older implementations if the core extension is available.
The simple piece of software I wrote to parse gl.xml for this information can be found here if you are interested.
Function loaders are only needed on Windows and Linux. Here's a quick overview of how you build for various OpenGL versions on different platforms.
Windows
The Windows development tools only contain headers for OpenGL 1.1. The conspiracy theorists would probably claim that Microsoft is not interested in making the use of OpenGL easy because it wants developers to use a proprietary API instead.
For anything beyond 1.1, you need to load the entry points dynamically by calling wglGetProcAddress(). Libraries like GLEW provide header files for higher OpenGL versions, and encapsulate the logic for loading the entry points.
Linux
I haven't done OpenGL programming on Linux. From what I hear, it requires function loading similar to Windows. I'll defer to #datenwolf's answer for the details.
Mac OS
Mac OS supports two main OpenGL feature sets:
OpenGL 2.1 with legacy features. This is used by including <OpenGL/gl.h>.
OpenGL 3.x and higher, Core Profile only. Used by including <OpenGL/gl3.h>.
In both cases, you don't need any dynamic function loading. The header files contain all the declarations/definitions for the maximum version that can be supported, and the framework you link against (using -framework OpenGL) resolves the function names.
The maximum version you can use at build time is determined by the platform SDK you build against. By default, this is he platform SDK that matches the OS of your build machine. But you can change it by using the -isysroot build option.
At runtime, the machine has to run at least the OS matching the platform SDK used at build time, and you can only use features up to the version supported by the GPU. You can get an overview of what version is supported on which hardware on:
https://developer.apple.com/opengl/capabilities/
http://support.apple.com/en-us/HT202823
Android, NDK
With native code on Android, you choose the OpenGL version while setting up the context and surface. Your code then includes the desired header (like <GLES2/gl2.h> or <GLES3/gl3.h>) and links against the matching libraries. There is no dynamic function loading needed.
If the target device does not support the version you are trying to use, the context creation will fail. You can have an entry in the manifest that prevents the app from being installed on devices that will not support the required ES version.
Android, Java
This is very similar to the NDK case. The desired version is specified during setup, e.g. while creating a GLSurfaceView.
The GLES20 class contains the definitions for ES 2.0. GLES30 derives from GLES20, and adds the additional definitions for ES 3.0.
iOS
Not surprisingly, this is very similar to Mac OS. You include the header file that matches the desired OpenGL ES version (e.g. <OpenGLES/ES3/gl.h>), link against the framework, and you're all done.
Also matching Mac OS, the maximum version you can build against is determined by the platform SDK version you choose. Devices you want to run on then have to use at least the OS version that matches this platform SDK version, and support the OpenGL ES version you are using.
One main difference is obviously that you cross compile the app on a Mac. iOS uses a different set of platform SDKs with different headers and frameworks, but the overall process is pretty much the same as building for Mac OS.
I post the following question at LunarG, as Issue #565, about Vulkan SDK redistributable parts for ready to go applications developed with Vulkan. I'd like to share it with Stack Overflow developers.
Let's say I have Vulkan application demo and wish to send it to
potential clients, in order to evaluate it. If I'd develop it using
SDK, what is the correct way to deploy it :
a) include the compatible SDK installer in a multi-install process ?
b) include some SDK's dlls and companion files ? Which ones ?
It also raises another question: Can I re-distribute SDK files ?
Karl Schultz, from LunarG, replied with the following:
On Windows, many IHVs include the Vulkan loader DLL in their install
packages, placing it in system32/vulkan-1.dll. So, in many cases, your
app might just work fine as long as the user has installed drivers
with Vulkan support.
You might also consider shipping only the RunTimeInstaller, which is
found in the SDK. This would let the user install the run time
(loader) as part of your application install. The RTI includes version
checking so that it doesn't clobber a newer version installed by IHV
drivers, or vice-versa. In short, this is probably the best way to go.
It would be better to include the RTI as part of the "multi-install
process" rather than include the entire SDK.
If your application needs layers or some other specific item from the
SDK, then you'd have to include those explicitly somehow.
Please check the licensing-related files within the SDK concerning
redistribution.
I'm a bit confused about when exactly I need to use an OpenGL function loader like GLEW. In general, it seems like you first obtain a window and valid OpenGL context and then attempt to load functions.
Sometimes these functions are referred to as extensions, sometimes they are called core functions as well. It seems like what's loaded and classified as 'core' and 'extension' is platform dependent. Are the functions that are loaded in addition to some base set?
Do you need to load functions in the same way on OpenGL ES platforms as well? Taking a quick look at GLEW, I don't see any explicit support for Open GL ES. Other GL function loader libs do explicitly mention support specifically for ES however (like https://github.com/Dav1dde/glad)
OpenGL functions (core or extension) must be loaded at runtime, dynamically, whenever the function in question is not part of the platforms original OpenGL ABI (application binary interface).
For Windows the ABI covers is OpenGL-1.1
For Linux the ABI covers OpenGL-1.2 (there's no official OpenGL ABI for other *nixes, but they usually require OpenGL-1.2 as well)
For MacOS X the OpenGL version available and with it the ABI is defined by the OS version.
This leads to the following rules:
In Windows you're going to need a function loader for pretty much everything, except single textured, shaderless, fixed function drawing; it may be possible to load further functionality, but this is not a given.
In Linux you're going to need a function loader for pretty much everything, except basic multitextured with just the basic texenv modes, shaderless, fixed function drawing; it may be possible to load further functionality, but this is not a given.
In MacOS X you don't need a function loader at all, but the OpenGL features you can use are strictly determined by the OS version, either you have it, or you don't.
The difference between core OpenGL functions and extensions is, that core functions are found in the OpenGL specification, while extensions are functionality that may or may be not available in addition to what the OpenGL version available provides.
Both extensions and newer version core functions are loaded through the same mechanism.
datenwolf's answer is great, but I wanted to clarify something you said in the first bullet point of your question.
Core and extension status is not platform-dependent or even mutually exclusive.
Core means that some feature was introduced in a certain version of OpenGL. There are core functions, which are things that are guaranteed to exist in version X.Y and there are even core extensions, which are extensions that were introduced alongside version X.Y. Core extensions provide the same functions, types, enums, etc. as the core feature only in an extension form that does not require a specific version.
Framebuffer Objects went core in OpenGL 3.0, and are slightly less restrictive than the EXT extension (GL_EXT_framebuffer_object) that predates OpenGL 3.0. However, it is not necessary to have an OpenGL 3.0 implementation to have access to the core version of FBOs - an OpenGL 2.1 implementation might offer the core functionality.
In the extension specification for GL_ARB_framebuffer_object, you will find:
Issues
(8) Why don't the new tokens and entry points in this extension have
"ARB" suffixes like other ARB extensions?
RESOLVED: Unlike most ARB extensions, this is a strict subset of
functionality already approved in OpenGL 3.0. This extension
exists only to support that functionality on older hardware that
cannot implement a full OpenGL 3.0 driver. Since there are no
possible behavior changes between the ARB extension and core
features, source code compatibility is improved by not using
suffixes on the extension.
That is the first mention of a core extension that I can recall, but it is not the last. Since then many ARB extensions have been created that "backport" (if you will) core functionality from a higher version.
Here is some sample output gathered by parsing gl.xml for another core extension:
>> Command: void glBufferStorage (GLenum target, GLsizeiptr size, const void *
data, GLbitfield flags)
* Provided by GL_ARB_buffer_storage (gl|glcore)
* Core in GL_VERSION_4_4 ( gl 4.4)
It is core in 4.4 (guaranteed to exist in a 4.4 implementation), but because the extension that provides it is glcore, this core function may be available in older implementations if the core extension is available.
The simple piece of software I wrote to parse gl.xml for this information can be found here if you are interested.
Function loaders are only needed on Windows and Linux. Here's a quick overview of how you build for various OpenGL versions on different platforms.
Windows
The Windows development tools only contain headers for OpenGL 1.1. The conspiracy theorists would probably claim that Microsoft is not interested in making the use of OpenGL easy because it wants developers to use a proprietary API instead.
For anything beyond 1.1, you need to load the entry points dynamically by calling wglGetProcAddress(). Libraries like GLEW provide header files for higher OpenGL versions, and encapsulate the logic for loading the entry points.
Linux
I haven't done OpenGL programming on Linux. From what I hear, it requires function loading similar to Windows. I'll defer to #datenwolf's answer for the details.
Mac OS
Mac OS supports two main OpenGL feature sets:
OpenGL 2.1 with legacy features. This is used by including <OpenGL/gl.h>.
OpenGL 3.x and higher, Core Profile only. Used by including <OpenGL/gl3.h>.
In both cases, you don't need any dynamic function loading. The header files contain all the declarations/definitions for the maximum version that can be supported, and the framework you link against (using -framework OpenGL) resolves the function names.
The maximum version you can use at build time is determined by the platform SDK you build against. By default, this is he platform SDK that matches the OS of your build machine. But you can change it by using the -isysroot build option.
At runtime, the machine has to run at least the OS matching the platform SDK used at build time, and you can only use features up to the version supported by the GPU. You can get an overview of what version is supported on which hardware on:
https://developer.apple.com/opengl/capabilities/
http://support.apple.com/en-us/HT202823
Android, NDK
With native code on Android, you choose the OpenGL version while setting up the context and surface. Your code then includes the desired header (like <GLES2/gl2.h> or <GLES3/gl3.h>) and links against the matching libraries. There is no dynamic function loading needed.
If the target device does not support the version you are trying to use, the context creation will fail. You can have an entry in the manifest that prevents the app from being installed on devices that will not support the required ES version.
Android, Java
This is very similar to the NDK case. The desired version is specified during setup, e.g. while creating a GLSurfaceView.
The GLES20 class contains the definitions for ES 2.0. GLES30 derives from GLES20, and adds the additional definitions for ES 3.0.
iOS
Not surprisingly, this is very similar to Mac OS. You include the header file that matches the desired OpenGL ES version (e.g. <OpenGLES/ES3/gl.h>), link against the framework, and you're all done.
Also matching Mac OS, the maximum version you can build against is determined by the platform SDK version you choose. Devices you want to run on then have to use at least the OS version that matches this platform SDK version, and support the OpenGL ES version you are using.
One main difference is obviously that you cross compile the app on a Mac. iOS uses a different set of platform SDKs with different headers and frameworks, but the overall process is pretty much the same as building for Mac OS.