There are many questions that explain the difference between API and library like this one and this one.
I understand that a library is a chunk of code that you can call from your own code, to help you do things more quickly/easily. An API is a part of a library of classes and methods which can be used by a user in their code. From my understanding, I classified OpenGL as a library not an API but when I read a book it says OpenGL is not a library it is an API.
Can you tell me which it is?
OpenGL is an API. Why? Because an API is a list of functions and tokens that are specified to behave in a certain way. An API is written down in a specification. The specification of OpenGL can be found at http://opengl.org/registry and specifications by itself are not something you can install and run on a computer system.
OpenGL is not a library. Why? Because a specification is just a normative text, which is something you can not use standalone. Note that among the specification documents for OpenGL there are also header files that can be use to compile a OpenGL program. But what's missing is actual code (library) that could be linked against. Something that can be linked against and behaves like specified by the OpenGL specification is called an implementation. But implementations are tied to the very same OpenGL specification and shipped as part of a operating system's graphics infrastructure.
Related
Where I can find C++ specification for Vulkan (same like the official C one on Khornos pages), describing the particular Vulkan api primitives and functions? Does it even exist (I was trying to find it with no success)?
Personaly I am using the C api even with C++ as I already got used to its style and it fits my needs perfectly (verbose, but you see everything), but I have to go through the code written by other people using C++ api. Usually Vulkan C++ api is just some syntactic sugar build upon the C api function calls, but sometimes digging through vulkan.hpp and trying to figure out what is going on is really annoying.
I am aware of this: https://github.com/KhronosGroup/Vulkan-Hpp
There is no "Vulkan C++ specification". There's a header file containing some functions and types that make using Vulkan more C++-friendly. But those are not part of any actual specification.
The mapping from "VulkanHpp" into regular C Vulkan is pretty obvious in most cases and can be deduced just from the nature of the APIs in question. vk::ImageCreateInfo means the same thing, with the same fields, as VkImageCreateInfo as defined by the Vulkan specification. The C++ wrapper is not trying to confuse users as to how it works.
This question already has answers here:
When do I need to use an OpenGL function loader?
(3 answers)
Closed 3 years ago.
I am learning now OpenGL and writing some geometrical abstractions over it for personal usage. I want my code to be maximally portable and I want to have GL context initialized in caller code (by means of FLTK, wxWidgets, WinAPI or any else supported platform).
I am reading now this popular article: https://learnopengl.com/Getting-started/Creating-a-window
Authors suggest there to use GLAD library, because this library provides creation of GL context (which does not fit me) and also it is used for 'retrieving addresses of functions' (quote: "Since there are many different versions of OpenGL drivers, the location of most of its functions is not known at compile-time and needs to be queried at run-time.").
My question is the following:
Does compiler really cannot get addresses of Opengl functions from GL-related .obj files which I specify in Linker Settings of Visual Studio? Do I really need to use wglGetProcAddress routine to refer to OpenGL functions? Is it possible to use OpenGL functions like any other functions from linked headers and .obj files?
Authors suggest there to use GLAD library, because this library provides creation of GL context (which does not fit me)
No, GLAD does not create or manage GL contexts in any way, and the website https://learnopengl.com/Getting-started/Creating-a-window never claims otherwise. They use GLFW for context and window management.
Does compiler really cannot get addresses of Opengl functions from GL-related .obj files which I specify in Linker Settings of Visual Studio?
No.
First of all, you do not specify OpenGL-related .obj files for the linker, but on Windows, you might use opengl32.lib, which is the import library file for opengl32.dll which comes with every windows version since Windows 95.
However, this DLL does not contain the OpenGL implementation you are typically using, but it contains Microsoft's OpenGL 1.1 GDI software rasterizer. The actual OpenGL implementation on windows is provided by an Installable Client Driver (ICD) which comes with your graphics driver. For OpenGL 1.0 and 1.1 functions, opengl32.dll will act as a trampoline and will forward the calls to the actual ICD DLL.
If you want to call any OpenGL function beyond OpenGL 1.1 (and that one is from 1997), you have to use the OpenGL extension mechanism in every case, as opengl32.dll does not provide these entry points at all, and the compiler/linker will of course not find them.
I've checked numerous posts and tutorial about using OpenGL and C++. There is one thing that still bothers me. In each tutorial you have some additional library like GLFW, GLU, GLUT, WIN32 and so on (mostly used for window creation). Although I was unable to find some tutorial using only OpenGL. The only clue is this answer syaing that you need to use some library for this.
Can someone explain how it really is? How it looks when I want to use code on different operating systems? Is application code written with OpenGL 100% portable?
You can't have a tutorial which uses only OpenGL just because it's an API which doesn't provide such functionality.
OpenGL is not meant to create a graphical context in an operating system and use it, it is meant only to work directly with the GPU through a set of defined functions.
So the main point is that what you are asking resides outside the purpose of OpenGL, which defines just a standard interface to graphical operations.
But many more or less complete libraries exist to handle this problem and you also quoted some, for example GLFW or SDL, which takes care of initializing the context and manage also additional issues (for example controls or sounds).
The product will be portable if a set of constraints is respected:
you are using a library which manages different OS for handling the graphical context (eg GLFW)
you are using an OpenGL profile which is supported by all the GPUs you mean to make your code work on
in case of portability between OpenGL and OpenGL ES you must ensure additional constraints since the latter managed certain things differently
I would like to start learning OpenGL, to use it in software written in C++ language. The natural thing I do when attempting to learn something new is acquiring proper literature and online tutorials.
With OpenGL however, I got stuck. Different literature and tutorials that I have checked almost immediately mention terms, like :
Unofficial OpenGL SDK
GLSL
FreeGLUT
SFLW
GLEW
GLFW
others ...
Even though I checked the websites of these tools or wiki entries, I still don't understand things like : what are they actually with relation to OpenGL, why use one and not another, what do they have in common, what are the differences... And probably most importantly, how do I find what I ( don't ) need ?
So I would very much like to hear an explanation on this topic. Reference to a proper online reading is good as well. Thank you.
Open Graphics Library (OpenGL) is a cross-language, cross-platform application programming interface (API) for rendering 2D and 3D vector graphics. As such, it only provides means for drawing basic primitives (like points, lines, triangles), but no high-level functionality. Let's work through your list:
The "Unofficial OpenGL SDK"
This is just a collection of libraries offering some (more or less) often required functionality, like loading image files, or working with 3D objects, or helper libraries for creating and managing OpenGL contexts (it does include some of the other libraries you mention, we're coming to that.) I wouldn't recommend using that SDK as a beginner, but just learn the basics and carefully select the additional libraries you want to use.
OpenGL Shading Language (abbreviated: GLSL or GLslang), is a high-level shading language based on the syntax of the C programming language.
This is not a separate tool, but a central concept of modern OpenGL. You will need it to write your shaders (which are required in modern GL). That's something you definitively have to learn, but the compiler for this language comes with your GL implementation, so this is nothing you have to install separately.
FreeGLUT, GLFW, SFLM
As I already said, OpenGL is defined platform-independent. One still needs a platform-specific API to actually create the OpenGL contexts and "connect" them to the windows (or whatever "drawables" there are on the platform). OpenGL does not even have a concept of a "window", and as such, also no means for input event handling, detecting window resizes. These libraries implement wrappers for those platform-specific GL binding APIs and the window and event management, so you can just create a OpenGL context and a suitable window without having to care about all those platform-specific details. FreeGLUT and GLFW are quite focused on providing a simple framework for OpenGL development, while SFML is a more generic multimedia framework (also supporting things like audio output) and is capable of creating OpenGL contexts and windows. Other such libraries would be SDL (which is often used for games), or Qt which supports OpenGL widgets.
GLEW is short for "OpenGL extension wrangler".
This is a OpenGL loading library. OpenGL is an extensible
API. As such, features might or might not be present on the machine your application is executed. Furthermore, the way the OpenGL is defined on some platforms, only a certain set of functions is guaranteed to be exported by the libraries. If you need features of newer versions, you have to use the extension mechanism. This means that, instead of directly linking a function at link time, you have to query the function pointers at runtime to get access to those functions. To simplify that process, such loader libraries as GLEW do exist. With GLEW, all you need to do is call glewInit() and then you can use any GL function as you like (as long as it is supported by the implementation), forgetting about all those details of the extension mechanism.
What you really "need" of this list: GLSL, but that's not a tool. The other stuff is for convenience, but I highly recommend using some platform-independent window and context management library (GLFW is quite lightweight, but it is hard to tell what you will need. For learning OpenGL, GLFW is surely a good choice.) and also some GL loader like GLEW.
I'm looking at the OpenGL wiki page, and I was curious about the following line:
For reasons that are ultimately irrelevant to this discussion, you must
manually load functions via a platform-specific API call. This boilerplate
work is done with various OpenGL loading libraries; these make this process
smooth. You are strongly advised to use one. —OpenGL Wiki
Intuitively, you would think they would just provide a header for you to include. So, what are the historic reasons for this?
EDIT :
Thanks for the answers, I see now that that OpenGL supports multiple implementations of its functions, so there is no one single DLL/SO that everyone links to. I also found these quotes helpful:
The OpenGL library supports multiple implementations of its functions. From MSDN
To accommodate this variety, we specify ideal behavior instead of actual behavior for certain GL operations. From GL Spec
When you run your program, opengl32.dll gets loaded and it checks in the Windows registry if there is a true GL driver. If there is, it will load it. For example, ATI's GL driver name starts with atioglxx.dll and NVIDIA's GL driver is nvoglv32.dll. The actual names change from release versions GL FAQ
I also found that Intel doesn't provide up-to-date implementation for OpenGL, so even though I have an i7-2500, I only have OpenGL 3.0 :(.
It has nothing to do with history. That's just how it is.
OpenGL implementations, by and large, come from some form of shared library (DLL/SO). However, this is complicated by the fact that you don't own the OpenGL "library"; it's part of the system infrastructure of whatever platform your code is running on. So you don't even know what specific DLL you might be using on someone else's computer.
Therefore, in order to get OpenGL function pointers, you must use the existing infrastructure to load them.
One of the main reasons is extensions: On every platform, OpenGL has always supported platform-specific extensions. These couldn't be part of the official headers, as they were usually added by the vendors in-between spec updates. In addition, those vendor-specific extensions may live in completely weird DLL/SO, for instance, deep inside the driver. There is also no guarantee that the driver DLL exports them under their "canonical" name, so OpenGL relied very early on platform-specific stuff to load a function pointer. This makes the whole extension thing feasible.
On all platforms, you usually do get some OpenGL without using extensions (OpenGL 1.4 or so), but as the extension method was successful and is easy to implement, everyone uses it now (similar for OpenCL!)
On the Mac, you don't need to load function pointers, you just include a header and link against the OpenGL framework.