I'm confused. I've been trying to start out with OpenGL, and I haven't had any success at all.
details:
I seem to have been trying to use Mesa 3D which isn't even strictly an official OpenGL implementation anyway. Does Mesa 3D even use the gpu? and I have version 4.0 (which is like an OpenGL version 1.3 implementation). I don't know how to get another implementation library; I don't even know what others there are. (Mesa 3D was provided with my dev-cpp compiler)
In fact, I don't really fully understand what OpenGL is.
Also, I cannot get freeglut or glut or glu to work. They're calling non-existing functions like gluOrtho and gluPerspective. Is this due to using Mesa 3D? Is there any way I could get these entire libraries to actually work?
In fact, I don't really fully understand what OpenGL is.
OpenGL in and itself is just a specification of an API: A set of functions you can call and special values and tokens and what the effects of each call are. Implementations then follow this specification to provide a working OpenGL.
OpenGL is rasterizing drawing API, optimized for the drawing of primitives in 3D space. I.e. you supply a stream of 3D coordinates and a drawing mode, i.e. draw points, lines or triangles, and OpenGL will then transform the 3D data into the 2D screen space and draw flat primitives on a canvas. Later versions of OpenGL are no longer strictly 3D to 2D, but require so called shaders, which are small programs that describe the transformation of arbitrary dimensional geometry into 2D screen space.
Additional functionality is the sampling and interpolation of image data (texturing) as an additional data source when drawing.
details: I seem to have been trying to use Mesa 3D which isn't even strictly an official OpenGL implementation anyway.
Why? If you're on Windows, then you should use the OpenGL implementation provided by the GPU driver, not some random library (though Mesa3D is not entirely random).
OpenGL is not actually some library you install, it's a set of functions provided by the GPU driver. For cases where the GPU drivers don't provide OpenGL you can use a software rasterizer implementation.
Does Mesa 3D even use the gpu?
Depends. On Windows Mesa3D is a software rasterizer only. However for X.org (Linux, FreeBSD, etc.) Mesa3D is the open source OpenGL frontend to the GPU drivers, so you get GPU acceleration through mesa there, if X.org is configured to use a driver that Mesa3D can use.
I don't know how to get another implementation library; I don't even know what others there are. (Mesa 3D was provided with my dev-cpp compiler)
Usually you get your OpenGL as part of the GPU drivers. On Linux when installing open source GPU drivers this automatically installs Mesa3D. But there are also closed source drivers and those use a entirely different codebase.
This is really important: You do not need a specialized OpenGL library to do OpenGL development.
Usually your compiler ships with a "opengl32.lib" (if on Windows – on other platforms you just tell the linker to link against the system OpenGL). However this is just sort of a table of contents for the linker, what an actual OpenGL implementation will offer.
On Windows the system opengl32.dll exports only OpenGL-1.1. For any functionality above this there is the so called extension mechanism to load higher version functions. You usually do this through a library (in this case really a library) like GLEW
Related
First off, I'm relatively new to this. I'm looking forward to picking up both SDL2 as well as SFML2 libraries for game dev. (and other stuff).
Now I know for a fact that both SDL2 and SFML2 are capable of creating OpenGL enabled contexts, through which OpenGL graphics programming may be done.
But online, I've read discussions wherein people said something to the effect of "SDL 1.2 is software accelerated, SDL2 and SFML2 are hardware accelerated by default". I know that software rendering is graphics using CPU alone. While Hardware rendering uses graphics cards/pipeline.
So my question is, with regards to these game libraries:
Part 1: when someone says one is software/hardware acc.by default, what does he mean? Is it that (my guess) if say SFML2 is hardware acc. by default, even basic 2d graphics are done by it using hardware rendering as the backend pipeline to do it, even if I didn't explicitly do any hardware-rendering programming in the code?
Part 2: And if that is true, is there any option within these libraries to set that to software acceleration/rendering?
Part 3: Which of these 2 libraries (SDL2 vs SFML2) has better overall performance/speed?
Thanks in advance for any answer and apologies if you found the question dumb.
Cannot say anything about SFML (but almost sure things are very close), but for SDL it is as you say. In SDL1 2d drawing implemented as blitting directly on display surface, and then sending this surface to display - so mostly software (although minor hw acceleration is still possible). SDL2 have SDL_Renderer and textures (which are GPU-side images or render targets) and any basic drawing that uses renderer may be accelerated by one or another backend. Which backend will be chosen depends on system your program runs and user settings - e.g. it would default to opengl for linux, d3d for windows (but still can use opengl), opengles for android/ios, etc..
You can use software renderer either by explicitly calling SDL_CreateSoftwareRenderer, or hint SDL to use software driver, or even override it by setting SDL_RENDER_DRIVER environment variable.
If you intend to use opengl for 3d graphics - then you just ignore all that and create window with opengl context as usual, and never use SDL_Renderer.
How I can use OpenGL without mesa? It's terrible - supports max. OpenGL 3.1.
I readed about loading openGL.so with dlopen but where is file to load, and how I can hang that?
Ah, I forgot, language is C++
Just linking to libGL.so is all that is necessary to use the hardware graphics driver.
If you have an NVIDIA or AMD graphics card and you have installed the nvidia or fglrx driver, you will get the maximum OpenGL version supported by your video card.
If you instead are using the open source nouveau, radeon, intel, or other graphics driver, Mesa will take over and you will have only the maximum version of OpenGL supported by Mesa (3.1) and the driver for your hardware. It will automatically use all hardware features it's capable of using.
You do not need to do any fancy dlopen tricks or anything else.
OpenGL is an open API to "standardize" the access to graphics pipeline. The graphics pipeline is supposed to be in a GPU! But this is not necessary! Mesa 3D is a an open-source implementation of the OpenGL specification that also contains a software implementation of a graphics pipeline (yes, software-based) that is supposed to deliver the same result of a regular GPU graphics pipeline (except for the speed, of course!).
You don't have to use MESA if you have GPU! In order to try OpenGL, I suggest you to read some basic tutorial of OpenGL:
http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html
http://www.opengl-tutorial.org/
dlopen() is used to load dynamic libraries. If you use helpers like GLFW or GLUT you don't need to care about those details.
What exactly does it mean to say that Mesa is an implementation of OpenGL? Don't the drivers of my Nvidia card implement all the OpenGL functions, etc.? So given that the drivers of my Nvidia card are taking Opengl calls and handing them off to the hardware, what exactly does Mesa do? Can someone clarify the distinction between Mesa and drivers?
Can someone clarify the distinction between Mesa and drivers?
Mesa provides the client side OpenGL interface for the open source GPU drivers based on the DRI2/DRM architecture. Or in other words: It's also a part of a driver.
If you've got the proprietary drivers from NVidia or AMD installed you don't need Mesa. If you want to use the open source drivers (nouveau, radeon, radeonhd, intel) you need Mesa.
I believe LinuxQuestions.org forum member geeman2.0 provided a good explanation for this matter:
OpenGL and Mesa aren't really two separate choices, but rather Mesa is a specific type of OpenGL.
OpenGL is simply an interface that defines a standard set of functions needed for drawing 3d graphics. It doesn't involve the actual code that makes these functions happen, it only specifies what the functions are called and what they are supposed to do.
An openGL implementation provides the actual code that runs the methods specified by the OpenGL standard. Without an implementation installed, you cannot run any opengl programs.
Mesa is just one of many OpenGL implementations, and is the most standard one included in linux distributions. It does all the work in software, which is why it is slow.
When you install Nvidia or ATI drivers for a fancy graphics card, these drivers provide a new OpenGL implementation that runs on the graphics card. This implementation would take the place of the Mesa implementation, but it is still an openGL implementation. That is, all of Mesa/ATI/NVidia drivers implement the same set of functions, they just do it in different ways, and they are all openGL.
Source
What exactly does it mean to say that Mesa is an implementation of
OpenGL?
First of all, OpenGL is an API Specification created between Khronos and the videocard manufacturer (Nvidia, ATI, Intel, etc), it's like an agreement on what functions the hardware is capable of.
Mesa is a software library for 3D computer graphics that provides a generic Khronos-compliant OpenGL implementation for rendering three-dimensional graphics on multiple platforms. So, for example, if you are running Linux you will probably have to install Mesa in order to generate any kind of graphics. For Microsoft Windows there is already an implementation installed.
Don't the drivers of my Nvidia card implement all the OpenGL
functions, etc.?
Yes, your Nvidia card driver implements OpenGL functions.
So given that the drivers of my Nvidia card are taking Opengl calls
and handing them off to the hardware, what exactly does Mesa do?
Your program communicates to Mesa, Mesa to your video card's driver, the driver to the actual GPU, the GPU sends the signal to the monitor for you to finally watch the drawing.
I want to start coding in OpenGL and C++ and I have a couple of questions:
1. Should I use OpenGL 4.2 or rather 3.x instead? OpenGL 4.x runs on Nvidia GTX 400+. Does that mean that it is widely supported or should I go for 3.x?
2. I found some headers and libraries in Windows SDK, but not all of them. Is there any place where I can find all libraries and headers for OpenGL? What I want to avoid is downloading old and different versions from all over the internet.
3. Does OpenGL cover input or is this part of the GDI+/WinAPI?
You should go for what you want to support. The major OpenGL version (3,4) is typically used for identifying hardware generations, while the minor versions are really targeted at functional releases, which should be independent of your hardware. For example: I have now 4.2 features while that didn't even exist when I bought this GPU. So you can count that up-to-date drivers will support the latest minor version. But no matter how you try, your GPU won't get new hw functions with a driver update. Note that a tricky part is that not all GPU's are still supported. This means driver updates are no longer provisioned and they could be stuck at some minor OpenGL version.
There are wrappers that do most things for you, but do not forget that you still need to link to the gl and possibly glu libraries and some platform-specific ones. I personally like the unofficial OpenGL SDK, glload is the library that you want. The other libraries are also quite useful.
OpenGL does not cover input, it is just for drawing. Also note that OpenGL does not create the default framebuffer for you. The default framebuffer is the thing you render to (usually in a window). This is done by platform specific functions, for windows this is WGL.
By this I mean, does Cairo draw lines, shapes and everything using opengl acelerated primitives or no? and if not, a library that does this?
The OpenGL backend certainly accelerates some functions. But there are many it can't accelerate. The fact that it's written against GL 2.1 (and thus can't use more advanced features of 3.x or 4.x hardware) means that there is a lot that it simply cannot accelerate.
If you are willing to limit yourself to NVIDIA hardware, NVIDIA just came out with the NV_path_rendering extension, which provides a lot of the 2D functionality you would find with Cairo. Indeed, it's possible that you could write a Cairo backend for it. The path rendering extension is only available on GeForce 8xxx hardware and above.
It's nifty in that it's focused on the vertex pipeline. It doesn't do things like gradients or colors or whatever. That's good, because it still allows you the use of a fragment shader. Which means you get to do pretty much whatever you want ;)
Cairo is designed to have a flexible backend for rendering. It can use OpenGL for rendering, though support is still listed as "experimental" at this point. For details, see using cairo with OpenGL.
It can also output to the X Window System, Quartz, Win32, image buffers, PostScript, PDF, and SVG, and more.