When there is a program,which consists of normal c++ code and opengl code.
So,both c++ and opengl are compiled and linked to ELF.
And,seemingly they both run on CPU.
Why opengl code has more power to paint on screen than c++ code ?
Why opengl code has more power to paint on screen than c++ code?
Because OpenGL merely sends drawing commands to the GPU, which is then doing the bulk work. Note that there are also OpenGL implementations that are not GPU accelerated and therefore not faster than other software rasterizers running on the CPU.
Unless you're talking about GLSL, there is no distinction between "C++ code" and "OpenGL code". It's all just C or C++, depending on what you're building. OpenGL is an API, a library that contains functions that do stuff.
Your code calls OpenGL functions, which are functionally no different from any other C++ function you might call. Functions in C++ do something, based on how they're implemented.
OpenGL functions tell the GPU what to do, using GPU-specific constructs. That's what OpenGL is for: to abstract away the specifics of hardware, so that you can write code that is not hardware-dependent. Your code that calls OpenGL functions should work on any OpenGL implementation that supports your minimum GL version (and extensions, if you're using those).
Similarly, std::fstream abstracts away differences between, say, Windows and Linux file access commands. Same API for the user, but it has different implementations on different OS's.
Related
I have been wanting to make a game in OpenGL, c++ for a while now and i would love some explanation on how exactly it works and what it is.
Can computer graphics be made without OpenGL ? most of the tutorials i have seen online show how to use OpenGL for the most basic graphics drawing, it is possible to directly interface with your GPU ?
How does OpenGL work on different CPU's and Operating systems ? As far as i know languages like c++ must be recompiled if they want to be used on an ARM processor and the such, is this not the case for GPU's in general ?
If you can indeed make graphics without OpenGL, does anybody still do this ? how much work and effort does OpenGL save in general and how complex are the systems that OpenGL facilitates for us?
Are there other libraries like OpenGL that are commonly used ? if not, will new libraries eventually come and take it's place or is it perfect for the job and not going anywhere ?
How exactly it works and what it is?
OpenGL defines an interface that you as a programmer can use to develop graphics programs (API). The interface is provided to you in form of header files that you include to your project. It is meant to be multiplatform, so that you can compile your code that uses OpenGL on different operating systems. People that manage the OpenGL specification do not provide the implementation of specified functionality. That is done by the OS and hardware vendors.
Can computer graphics be made without OpenGL?
Yeah, sure. You can e.g. calculate the whole image manually in your program and then call some OS-specific function to put that image on the screen (like BitBlt in Windows).
How does OpenGL work on different CPU's and Operating systems?
Each OS will have its own implementation of OpenGL specification that will usually call the hardware drivers. So let's say you have machine with Windows OS and Nvidia graphics card. If you run some program that calls glDrawElements it will look like this:
your_program calls glDrawElements
which calls glDrawElements implementation written by people from Microsoft
which calls Nvidia drivers written by people from Nvidia
which operates the HW
If you can indeed make graphics without OpenGL, does anybody still do this?
Yeah sure. Some people might want to implement their own rendering engine from ground up (although that is really hardcore thing to do).
Are there other libraries like OpenGL that are commonly used ? if not, will new libraries eventually come and take it's place or is it perfect for the job and not going anywhere ?
Sure. There is DirectX that is maintained by Microsoft and targets only Windows platforms and the Vulkan that can be seen as successor to OpenGL.
I am relatively new to graphic programming so I wanted to start from the very basic. I see there is library like PyOpenGl which provides binding to the opengl api itself. Now, I really want to create things like PyOpenGl on my own so I can understand how everything work in the process.
Is it possible for me to creates library like PyOpenGl or GLFW? If so please give me some general tips of what should I do.
If not please explain to me why I can't create my own binding and I do apologize if my question above sounds absurd.
PyOpenGL is a fairly thin wrapper that, for the most part, simply turns Python function calls into calls of native machine code functions of the same name. There are a few little details like calling conventions in the mix, but these are actually boring stuff. The fact is that (as far as OpenGL is concerned) the source code you write in Python with PyOpenGL looks almost identical to the source code you'd write in C. There are a few "smart" things PyOpenGL does, like providing means to interface NumPy arrays to OpenGL calls that take a data pointer parameter, but that's just house keeping.
And when you do OpenGL calls in C or – even more extreme – assembly language (perfectly possible) that's the lowest level you can go (with OpenGL), short of writing your own GPU device driver. And writing a GPU device driver is super hard work; it takes literally millions of lines of C code (NVidia's OpenGL implementation is said to consist of about ~40M LoC, there are open source drivers for AMD and Intel GPUs, and each of them have MLoC, too).
If you're interested in some middle ground, have a look at the Vulkan API. If writing higher level wrappers for graphics is your thing I'd suggest you implement some higher level API / renderer for Vulkan and interface it to Python. This is likely to be much more rewarding, as a learning experience (IMHO).
The OpenGL API lives in the driver for the graphics card. All OpenGL functions are there. You only need to know how to get them. As Spektre said, the proccess is:
Create an OpenGL context. This is a job for the OS. Each OS has its
way and its issues. Read https://www.khronos.org/opengl/wiki/Load_OpenGL_Functions
Define function pointers as glext.h does and then extract them from
the driver. Apart from standard OpenGL funcs, vendors add their own
ones, called "extensions". You can see how GLEW does this job. If you want to set all functions and extensions then make a script that uses glext.h because there are about one thousand of them.
You can download glext.h from https://www.opengl.org/registry/
Doing something like GLFW requires, added to the previous two points, knowing how to create a window and handle its messages for keyboard and mouse. Again this is OS dependant. On Windows there is a way. On Linux it depends on the window manager used, GTK+ for example. Or X11 directly. Or...
Anyhow my best advise is that you can read how GLEW and GLFW did, looking into their code. BUT don't lose much time on it. Prefer getting experience on OpenGL and let those "diggins" for later time.
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.
As you probably know, C++ has no standard graphics library. Most games use DirectX or OpenGL.
But how do those libraries actually work? In other words, how can the third-party libraries draw graphics if there's no mechanism for it in C++? Are they just written in another language?
Specifically DirectX and OpenGL work by calling the operating system and/or the video hardware driver. The driver, in turn, does the actual drawing by interacting with the graphical device. The exact details of interaction vary from one video card to another.
Back in the DOS days, C++ programmers could work with the hardware directly. This was accomplished in two ways. First, by writing to/reading from a special memory block ("framebuffer") where the pixels or text were stored. It was a span of memory at a known address, so to work with it you had to cast an integer constant to a pointer and work with that pointer. Purely C++ mechanism. The other way of interaction was reading from/writing to I/O ports. Now, this is a mechanism that is not directly supported by C, unless you count inline assembly or compiler intrinsics. There were two library functions that would wrap these two operations (literally, wrappers around two CPU commands - INP and OUTP), but most programmers would just use a one-line inline assembly snippet instead.
Even now, most video hardware interaction boils down to these two pathways - framebuffer and I/O ports (DMA and interrupts are typically not used for graphics). But we application-level programmers don't get to see those. This is driver stuff.
One modern caveat has to do with protected mode; in protected mode, the C pointers are not the same as underlying physical addresses. Simply typecasting 0xA0000 to a pointer won't get you to a framebuffer, even in kernel mode. However, kernel-level code (i. e. a driver) can request that the memory manager give it a pointer that corresponds to a specific physical address.
They will transfer their calls to the driver which will send them to the graphic card.
DirectX and OpenGL opperate on a pretty low level. That is you say "draw a triangle, now draw a square". Normally programmers then wrap these calls into C++ classes that provide higher level functionality, such as "Draw a model, draw a tree". This is known as an engine.
I'd recommend taking a look at the NeHe tutorials for more info: http://nehe.gamedev.net/
So for example a call to draw a triangle in OpenGL looks like this:
GLBegin(BEGIN_POLYGONS);
GLVector3(0,0,0);
GLVector3(10,10,0);
GLVector3(-10,10,0);
GLEnd();
And like I said, see the above link to the NeHe tutorials, they are all in C/C++
What is the difference between OpenGL and Direct3D? Are they truly different implementations to accomplish the same things (like Java and Mirosoft's CLR [.NET])?
They are very different graphics API's. But it's fair to say they mostly accomplish the same thing. DirectX is probably the API of choice if you are developing a game under windows (or a game for XBOX), and OpenGL is the choice if you want cross-platform support. Mac OS uses GL, as does the iPhone, for example, and many windows games also support OpenGL.
Because OpenGL was developed over a long time and 'by committee', it comes with a lot of baggage - the API has some older options that aren't really relevant today. That's one of the reasons for OpenGL ES; it cuts out all the junk and makes for an easier target platform.
DirectX on the other hand is controlled by Microsoft, and as such it has a more 'modern' feel to it (it's based on COM components, so is highly object oriented). MS often update the API to match new hardware.
Sometimes you don't have the luxury of choice (iphone for example can't run DX). But often it just comes down to personal preference/experience. If your a long-time graphics programmer, you tend to get pretty familiar with both...
Google is your friend in this case...there's a good Wikipedia article contrastring the two libraries:
Comparison of OpenGL and Direct3D
If memory serves, OpenGL was the open implementation before Direct3D came out. Direct3D was then based off of OpenGL...but quickly diverged and became it's own distinct library.
UPDATE
Looks like my memory is shot...
Direct3D was developed independtly of OpenGL.
Direct3D and OpenGL are different API's used to accomplish the same thing.
The major differences between D3D and GL is that D3D is Object Oriented and GL is not.
D3D9 and GLES2 basically have the same features. In fact if you plan on using OpenGL and do not need any GL3 or GL4 features you should base all you code on the GLES2 API(all GLES2 features are in GL2, but not the other way around).
If possible you should always use D3D over GL on windows, as multithreading and driver support is flaky. Take the netbooks for example, they support D3D's HLSL at ShaderModel 2 but don't support the equivalent for GLSL, they only support a fixed pipeline for GL.