I just can't find them anywhere. The most important part for me is the hardware acceleration, and I have no idea if there is a performance or openGL version compatibility requirement that the video card has to follow.
The minimum system requirements will depend alot more on the application that you are writing than what SDL2 does.
If you just create a standard window and render SDL will use what it can find and what it thinks is best either OpenGL, OpenGL ES, Direct3D or use the old style software rendering for machines that can't do any of the other. So if a computer can support an OS that SDL runs on then you will almost always (I just said almost since there can possible be exceptions) be able to run these type of apps (Video card not a requirement, but having one will greatly increase programs drawing speed).
You can also be creating a OpenGL application directly and then it depends on what type of context you are making what the video card has to support.
You can find most of the information here: http://wiki.libsdl.org/moin.fcg/MigrationGuide
under the Video section. It's actually how to port from 1.2 to 2.0 , but it explains the new Video Pipeline pretty well.
Hope thats what you were looking for.
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.
Ok, I know that online there are millions of answers to what OpenGL is, but I'm trying to figure out what it is in terms of a file on my computer. I've researched and found that OpenGL acts as a multi-platform translator for different computer graphics cards. So, then, is it a dll?
I was wondering, if it's a dll, then couldn't I download any version of the dll (preferably the latest), and then use it, knowing what it has?
EDIT: Ok, so if it's a windows dll, and I make an OpenGL game that uses a late version, what if it's not supported on someone else's computer with an earlier version? Am I allowed to carry the dll with my game so that it's supported on other windows computers? Or is the dll set up to communicate with the graphics card strictly on specific computers?
OpenGL is constantly being updated (whatever it is). How can this be done if all it's doing is communicating with a graphics card on a bunch of different computers that have graphics cards that are never going to be updated since they're built in?
There are two "parts" to OpenGL - the specification that's updated by the Khronos Group once every few months, and the driver that's written by your graphics card manufacturer specifically for your graphics card model.
The OpenGL specification essentially details how everything about the OpenGL API should work - what the expected behavior should be, when something is considered unexpected behavior, when to throw which errors, etc. The specification lets the driver writers know exactly what they need to do and lets application writers know what to expect from a driver. This is what OpenGL really "is" - the glue that holds applications and drivers together. You can read all the specifications for each version here.
Then there's drivers that implement the OpenGL API and are considered compliant to the specification. The driver does exactly what you'd expect it to do - copy data to and from the graphics card's memory, write data to graphics card registers, keep track of state, process vertices, compile shaders, instruct hundreds of stream processors to simultaneously transform vertices and fill pixels, etc. Without OpenGL, each graphics card model would have a separate, slightly faster API that would only work for that one graphics card because of the way it was structured. With OpenGL, the drivers are all written against the same API and an application's code will run on all graphics cards.
Compliance to the OpenGL specification doesn't change with driver updates. Most driver updates will either fix minor bugs or do some internal optimizing.
I know at one point there was a small bug with ATI driver where you had to call glEnable(GL_TEXTURE_2D); before you could generate mipmaps the OpenGL 3 way (glGenerateMipMaps()) despite GL_TEXTURE_2D being deprecated as a possible value for glEnable(). I'm not sure if it's fixed now, but it's certainly the type of edge case that can easily be overlooked by driver writers.
As for optimizations, there's a lot to optimize. Maybe there's another way to optimize shaders when they're being compiled, maybe there's a more efficient way to distribute work between the stream processors, I don't know.
OpenGL is a cross-platform API for graphics programming. In terms of compiled code, it will be available as an OS-specific library - e.g. a DLL (opengl32.dll) in Windows, or an SO in Linux.
You can get the SDK and binary redistributables from OpenGL.org
Depending on which language you're using, there may be OpenGL wrappers available. These are classes or API libraries designed to specifically work with your language. For example, there are .NET OpenGL wrappers available for C# / VB.NET developers. A quick Google search on the subject should give you some results.
The OpenGL API occasionally has new versions released, but these updates are backwards-compatible in nature. Moreover, new features are generally added as extensions, and it's possible to detect which extensions are present and only use those which are locally available and supported... so you can build your software to take advantage of new features when they're available but still be able to run when they aren't.
The API has nothing to do with individual drivers -- drivers can be updated without changing the API, and so the fact that drivers are constantly updated does not matter for purposes of compatibility with your software. On that account, you can choose an API version to develop against, and as long as your target operating systems ships with a version of the OpenGL library compatible with that API, you don't need to worry about driver updates breaking your software's ability to be dynamically linked against the locally available libraries.
I am aware that there were similar questions in past few years, but after doing some researches I still can't decide where from and what should I learn.
I would also like to see your current, actual view on modern OpenGL programming with more C++ OOP and shader approach. And get sure that my actual understanding on some things is valid.
So... currently we have OpenGL 4.2 out, which as I read somewhere requires dx11 hardware
(what does it mean?) and set of 'side' libraries, to for example create window.
There is the most common GLUT, which I extremely hate. One of main reason are function calls, which doesn't allow freedom in the way how we create main loop. As some people were telling, it was not meant for games.
There is also GLFW, which actually is quite nice and straight-forward to me. For some reason people use it with GLUT. ( which provides not only window initialisation, but also other utilities? )
And there is also SFML and SDL ( SDL < SFML imo ), whereas both of them sometimes need strange approach to work with OGL and in some cases are not really fast.
And we have also GLEW, which is extension loading utility... wait... isn't GLUT/GLFW already an extension? Is there any reason to use it, like are there any really important extensions to get interested with?
Untill now we have window creation (and some utilities), but... OGL doesn't take care of loading textures, neither 3D models. How many other libs do I need?
Let's mention education part now. There is (in)famous NeHe tutorial. Written in C with use of WinApi, with extremely unclear code and outdated solutions, yet still the most popular one. Some stuff like Red Book can be found, which are related to versions like 2.x or 3.x, however there are just few (and unfinished) tutorials mentioning 4.x.
What to go with?
So... currently we have OpenGL 4.2 out, which as I read somewhere requires dx11 hardware (what does it mean?) and set of 'side' libraries, to for example create window.
DX11 hardware is... hardware that has "supports DirectX 11" written on the side of the box. I'm not sure what it is you're asking here; are you unclear on what Direct3D is, what D3D 11 is, or what separates D3D 11 from prior versions?
FYI: D3D is a Windows-only alternative to using OpenGL to access rendering hardware. Version 11 is just the most recent version of the API. And D3D11 adds a few new things compared to D3D10, but nothing much that a beginner would need.
OpenGL is a specification that describes a certain interface for graphics operations. How this interface is created is not part of OpenGL. Therefore, every platform has its own way for creating an OpenGL context. Windows uses the Win32 API with WGL. X-Windows uses the X-Windows API with GLX functions. And so forth.
Libraries like GLUT, GLFW, etc are libraries that abstract all of these differences. They create and manage an OpenGL window for you, so that you don't have to dirty your code with platform-specific details. You do not have to use any of them.
Granted, if you're interested in learning OpenGL, it's best to avoid dealing with platform-specific minutae like how to take care of a HWND and such.
And we have also GLEW, which is extension loading utility... wait... isn't GLUT/GLFW already an extension? Is there any reason to use it, like are there any really important extensions to get interested with?
This is another misunderstanding. GLUT is a library, not an extension. An OpenGL extension is part of OpenGL. See, OpenGL is just a specification, a document. The implementation of OpenGL that you're currently using implements the OpenGL graphics system, but it may also implement a number of extensions to that graphics system.
GLUT is not part of OpenGL; it's just a library. The job of GLUT is to create and manage an OpenGL window. GLEW is also a library, which is used for loading OpenGL functions. It's not the only alternative, but it is a popular one.
Untill now we have window creation (and some utilities), but... OGL doesn't take care of loading textures, neither 3D models. How many other libs do I need?
OpenGL is not a game engine. It is a graphics system, designed for interfacing with dedicated graphics hardware. This job has nothing to do with things like loading anything from any kind of file. Yes, making a game requires this, but as previously stated, OpenGL is not a game engine.
If you need to load a file format to do something you wish to do, then you will need to either write code to do the loading (and format adjustment needed to interface with GL) or download a library that does it for you. The OpenGL Wiki maintains a pretty good list of tools for different tasks.
There is (in)famous NeHe tutorial. Written in C with use of WinApi, with extremely unclear code and outdated solutions, yet still the most popular one. Some stuff like Red Book can be found, which are related to versions like 2.x or 3.x, however there are just few (and unfinished) tutorials mentioning 4.x.
What to go with?
The OpenGL Wiki maintains a list of online materials for learning OpenGL stuff, both old-school and more modern.
WARNING: Shameless Self-Promotion Follows!
My tutorials on learning graphics are pretty good, with many sections and is still actively being worked on. It doesn't teach any OpenGL 4.x-specific functionality, but OpenGL 3.3 is completely compatible with 4.2. All of those programs will run just fine on 4.x hardware.
If you are writing a game, I would avoid things like GLUT, and write your own wrappers that will make the most sense for your game rendering architecture.
I would also avoid OpenGL 4.2 at this point, unless you only want to target specific hardware on specific platforms, because support is minimal. i.e., the latest version of Mac OSX Lion just added support for OpenGL 3.2.
For the most comprehensive coverage of machines made in the last few years, build your framework around OpenGL 2.1 and add additional support for newer OpenGL features where they make sense. The overall design should be the same. If you're only interested in targeting "current" machines, i.e. machines from late 2011 and forward, build your framework around OpenGL 3. Only the newest hardware supports 4.2, and only on Windows and some Linux. If you're interested in targeting mobile devices and consoles, use OpenGL ES 2.0.
GLEW loads and manages OpenGL Extensions, which are hardware extensions from different vendors, as opposed to GLUT which is a toolkit for building OpenGL applications, completely different things. I would highly recommend using GLEW, as it will provide a clean mechanism for determining which features are available on the hardware it is being run on, and will free you from the task of having to manually assign function pointers to the appropriate functions.
OpenGL SuperBible is a pretty good book, also check OpenGL Shading Language. Everything you do with modern OpenGL is going to involve the use of shaders - no more fixed functionality - so your biggest challenge is going to be understanding GLSL and how the shader pipelines work.
I'm currently learning modern OpenGL as well. I've also had hard time finding good resources, but here's what I've discovered so far.
I searched for a good book and ended up with OpenGL ES 2.0 Programming Guide, which I think is the best choice for learning modern OpenGL right now. Yes, the book is about OpenGL ES, but don't let that scare you. The good thing about OpenGL ES 2.0 is that all the slow parts of the API have been removed so you don't get any bad habits from learning it while it's still very close to desktop OpenGL otherwise, with only a few features missing, which I think you can learn rather easily after you've mastered OpenGL ES 2.0.
On the other hand, you don't have the mess with windowing libraries etc. that you have with desktop OpenGL and so the book on OpenGL ES won't help you there. I think it's very subjective which libraries to use, but so far I've managed fine with SDL, ImageMagick and Open Asset Import Library.
Now, the book has been a good help, but apart from that, there's also a nice collection of tutorials teaching modern OpenGL from ground up at OpenGL development on Linux. (I think it's valid on other OSes the name nevertheless.) The book, the tutorials and a glance or two every now and then to the Orange Book have been enough in getting me understand the basics of modern OpenGL. Note that I'm still not a master in the area, but it's definitely got me started.
I agree that it's king of hard to get in to OpenGL these days when all the tutorials and examples use outdated project files, boken links etc, and if you ask for help you are just directed to those same old tutorials.
I was really confused with the NeHe tutorials at first, but when I got a little better understanding of C, compiling libraries on UNIX and other basic stuff, it all fell into place.
As far as texture loading, I can recommend SOIL:
http://www.lonesock.net/soil.html
I'm not sure but I recall I had trouble compiling it correctly, but that may have been my low experience at the time. Give me a shout if you run into trouble!
Another usefull tip is to get a Linux VM running and then you can download the NeHe Linux example code and compile it out of the box. I think you just need GLUT for it to work.
I also prefer GLFW before GLUT, mainly because GLUT isn't maintained actively.
Good luck!
The major point of modern OpenGL is tesselation and new type of shader programs so i would like to recommend to start from a standalone tutorial on OpenGL 4 tesselation, i.e: http://prideout.net/blog/?p=48
After manuals and tutorials a good follow-up is to take a look at the open-source engines out there that are based on top of "new" OpenGL 3/4. As one of the developers, I would point at Linderdaum Engine.
"Modern OpenGL programming with more C++ OOP and shader approach" makes me mention Qt. It hasn't been mentioned yet but Qt is a library that is worth learning and is the easiest way to write cross platform C++ apps. I also found it the easiest way to learn OpenGL in general since it easily handles the initialization and hardware specific code for you. Qt has it's own math libraries as well so all you need to get started with OpenGL is Qt. VPlay is a library that uses Qt to help people make games easily so there are obviously some people using Qt to make games as well.
For a short introduction to Qt and OpenGL see my post here.
I will mention that since Qt abstracts some OpenGL code, if you are trying to use the Qt wrappers, the API is slightly different than just OpenGL (although arguably simpler).
As for my vote for good tutorials or book check out Anton's OpenGL tutorials and Swiftless tutorials. Anton's ebook on Amazon is also rated higher than any other OpenGL published resource I have seen so far (and far cheaper).
I want to be able to render into an OpenGL render window using DirectX. This is because the features i'm after are only supported in DirectX.
I have heard it is possible to do this a few years ago and i'm hoping it should still be possible.
I'd imagine it will involve pointing DirectX to the correct part of VRAM and the correct depth buffer.
Also a tutorial or simply an explanation would be extremely useful.
At least NVIDIA has the NV_DX_interop extension, which let's you use Direct3D 9 buffers/textures/surfaces directly as OpenGL buffers/textures/renderbuffers (therefore being the other way around). But I don't have any experience with this and I don't know if it is widely supported or actually works any good.
It would be more interresting which features you think are only available in Direct3D. Maybe we can show you how to achieve it with OpenGL, as there are not many features (if any) that are available in Direct3D and not in OpenGL. Although if you got an ATI card, being available and actually working correctly may sometimes be two seperate things.
Mixing OpenGL and Direct3D will not work, and AFAIK it never used to. May I ask, which features of Direct3D you require, that OpenGL doesn't offer?
You can. At least for nVIDIA! Check NV_DX_interop. But however, EVERY DirectX feature is supported in OpenGL as OpenGL is more RAW / Low level than DirectX! Just the way it is implemented may be different. Again, tell us WHICH feature of DirectX you want and I can tell you hints how to reimplement it.
One specific example of a difference between OpenGL and Direct3D, which is something I am researching myself, is that in DirectShow (a subset of Direct3D), there are video capture filters for my Panasonic DVCPRO-HD based cameras. So the live streams collected via that API, I would like to use as inputs into OpenGL libraries. One such library is OpenFrameWorks, which is OpenGL based. I am looking to see how efficient I can make this transfer. The existing OpenFrameWorks Video API uses a slightly older and deprecated DirectShow API, and uses a brute force strategy for getting pixels from DirectShow over to OpenFrameWorks.
I know that if the openGl implementation does not find a suitable driver it happily falls back and render everything in software mode. It's good for graphics applications but it is not acceptable for computer games.
I know many users using Windows XP and if the user does not install the video card driver for his GPU then the OpenGL won't be hardware accelerated (while DirectX is or if not it will throw errors).
Is there a better (and possibly cross platform) way to determine if OpenGL uses the hardware acceleration than measuring the FPS and if it's too low notify the user?
I know that games like Quake3 can find it out somehow...
It seems that there is no direct way to query OpenGL for this but there are some methods that may help you to determine if hardware acceleration is present. See here for Windows ideas. In a UNIX environment glxinfo | grep "direct rendering" should work.
See also glGetString and 5.040 How do I know my program is using hardware acceleration on a Wintel card?
This previous answer suggests that checking to see if the user only has OpenGL 1.1 may be sufficient.
How to write an installer that checks for openGL support?