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.
Related
According to Apple, OpenGL is no longer supported. However, it appears v4.1 of OpenGL was supported on many devices as of July 28, 2020. I have a 2020 Macbook Pro 16" model, which does not show up on the list provided above. While I am sure some form of compatibility exists on my device, I am unsure how I can develop with OpenGL when modern versions are deprecated.
I wish to be developing between my Macbook Pro running Big Sur and my Windows desktop. For this reason, I obviously do not wish to focus on a device-specific library such as Direct3D or Metal. Is it possible to work with newer versions of OpenGL (such as OpenGL 4.6) despite support not being directly provided by Apple? I've heard AMD video cards do not play well with OpenGL, so what options am I left with?
Built-in OpenGL on macOS works a little bit different from other platforms like Windows or Linux. On Windows, system-provided opengl32.dll doesn't actually implement OpenGL but is rather a proxy-library dynamically loading functions from a driver provided by a graphics card vendor. Graphics card vendors provide drivers independently from Microsoft and OpenGL capabilities can be implemented without Microsoft approval.
In contrast, macOS is much more closed system, where all graphic drivers are part of the system and cannot be (normally) updated without updating system itself. Apple holds the full control over OpenGL functionality in system and doesn't give graphics card vendors any way to deliver users more up-to-date OpenGL features (even when their hardware supports them on other systems).
This is quite unpleasant situation for a developer of multi-platform software, as Apple steadily pushes to their platform-specific APIs like Metal as the only choice, which implies a stronger vendor-lock and/or a more expensive development.
An alternative to using platform-specific APIs directly could be using a proxy-library implementing a multi-platform API on top of platform-specific API. So far, currently known options:
Apple's OpenGL implementation over Metal.
Unfortunately, it has stuck on OpenGL 4.1, and there is no reason to expect the version will ever grow up; the library could be even removed in some newer macOS.
You may already notice that information provided by a system library on modern macOS versions mentions Metal, so that it is already a wrapper over other graphics API (although Apple may cheat by accessing some internals).
MoltenVK, an open-source Vulkan 1.1 implementation over Metal.
This is not an OpenGL library, but Vulkan is another multi-platform graphics API and some references tells that MoltenVK in current state is solid enough for using in real projects, and Vulkan 1.1 is expected to give more features than outdated OpenGL 4.1 (though, I cannot confirm this personally, just my expectations).
MoltenGL, a closed-source OpenGL ES 2.0 implementation over Metal.
As current implementation is limited to OpenGL ES 2.0 (e.g. much lower than Apple's built-in OpenGL / OpenGL ES libraries), it looks quite useless...
Google ANGLE, an open-source OpenGL ES implementation over other APIs.
So far, ANGLE implements only OpenGL ES 2.0 over Metal, and OpenGL ES 3.1 (3.2 in progress) over Vulkan. So that with more layers like MoltenVK it could theoretically give more, if layers will not blow up ;). However, even OpenGL ES 3.2 doesn't look good enough compared to OpenGL 4.1. There is also MetalANGLE - an ANGLE library fork adding iOS support and some extra features.
Zink, an open-source OpenGL implementation over Vulkan.
Zink already implements OpenGL 4.6 on Linux (supported OpenGL version depends on exposed Vulkan features and extensions).
There is a work-in-progress making this Mesa Gallium driver working on top of MoltenVK on macOS.
To me, it looks that sticking to OpenGL 4.1 (provided by Apple) for a while is quite a good option in case if your application may afford losing some features requiring higher version of OpenGL. Although Apple has deprecated OpenGL in SDK, so far it looks non-realistic that it will be actually removed in nearest future within newer macOS updates; even Apple M1 GPU received OpenGL 4.1 support on macOS Big Sur. Don't know if Apple has some strategy black-listing applications using deprecated APIs from AppStore market (e.g. system will support OpenGL, but you will not be able publishing application on AppStore), but this might become an issue in some future. Alternative OpenGL 4.6 implementations (on top of Metal or on top of Vulkan-on-top-of-Metal) might come in some distant future.
Relying on Vulkan-on-top-of-Metal implementations might be most provisional choice, but it will certainly require more efforts to develop a graphics engine on top of Vulkan instead of OpenGL. Cannot comment, though, how current MoltenVK implementation is comparable to native Vulkan implementations on Windows for the same graphics hardware (by features/performance/limitations). Of course, using some existing graphics engine already implemented on top of several graphics APIs (Vulkan/Metal/Direct3D/OpenGL/OpenGL ES) will also take this maintenance burden from you, but this is out of scope of initial question.
#gkv311's answer is quite comprehensive. I'll add the following thoughts (full disclosure, I am the lead dev on the MoltenVK and MoltenGL projects):
IMHO, the Vulkan eco-system is your best bet for future-proofing game dev across the largest number of platforms. Here is a good summary of API layering options, based on that approach, allowing options for running OpenGL or DX over Vulkan, and/or Vulkan over Metal, DX, OpenGL, etc.
Some of these layering options can be stacked. For instance, Zink and DXVK can run on top of MoltenVK, providing OpenGL-over-Vulkan-over-Metal and DX-over-Vulkan-over-Metal functionality.
As far as Vulkan goes, MoltenVK has good performance, and good industry traction, being used by a number of AAA games ported from Windows origins, or running on top of Wine. If anyone has any questions, or wants to query some of those game developers, I suggest asking a question in the MoltenVK Discussions area.
MetalANGLE has emerged as another open-source option for OpenGL ES.
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'm a relative beginner with OpenGL (I'm not counting the ver. 1.1 NeHe tutorials I've done, because I'm trying to learn to do it the modern way with custom shaders), and I don't quite grasp how the different versions work, which ones require hardware changes, and which ones only require updates to the driver. Also, I've tried to find more details about how GLEW works (without diving into the code - yet), and it's still not clicking. While learning, I'm trying to find a balance between forward and backward compatibility in my code, especially since I'm working with older hardware, and it could become the basis of a game down the road. I'm trying to decide which version of GL and GLSL to code for.
My specific question is this: Why, when I use the GLEW (2.7) library (also using GLFW), does GLEW_VERSION_3_2 evaluate to true, even though the advertising for my GPU says it's only 2.0 compliant? Is it emulating higher-version functionality in software? Is it exposing hardware extensions in a way that makes it behave transparently like 3.2? Is it just a bug in GLEW?
It is an integrated Radeon HD 4250.
Then whatever advertisement you were looking at was wrong. All HD-4xxx class GPUs (whether integrated, mobile, or discrete cards) are perfectly capable of OpenGL 3.3. That ad was either extremely old, simply incorrect, or you read it wrong.
I've been looking for OpenGL version 2.0 or higher, but I haven't found anything I could use so far. There is no download section on the official website and google finds mostly stuff like OpenGL Viewer or OpenGL Screen Saver, but I am looking for OpenGL to develop games/graphics/vizualizations ( precisely version 2.0, but I know that higher versions are also compatible with 2.0 then they are also OK ). Could someone please give me a source, which I could get appropriate OpenGL for my project from? I've managed only to download one, but it didn't work, because it was created for 32bit OS, and I use 64bit windows 7. Does anyone know how to handle this problem as well?
this is my graphic card : NVIDIA GeForce 9600M GS
You don't have to download an SDK to use OpenGL in 64-bit applications on Windows. All you need is a 64-bit capable compiler, and the Windows Platform SDK (which comes bundled with Microsoft Visual Studio).
But there is a catch: Microsoft's OpenGL implementation hasn't been updated since OpenGL 1.1, and to use functionality from later versions OpenGL, you need to use OpenGL-extensions. Luckily, some nice people has made GLEW, a library that does the extension-work for you and allows you to simply compile OpenGL 2.0 (and later, as GLEW is updated) source code for Windows. Perhaps this is what you're looking for?
kusma is completely right, but maybe you'll need more precise directions.
First you'll need OpenGL libraries. These will be given with your Visual Studio / mingw / whatever installation.
Then you'll need to create an OpenGL window. You can do it with windows functions, but it is a nightmare. You should go for something like GLFW.
Then you'll need something to deal with openGL extensions ( as kusma said, you don't want OpenGL 1.1 only ). Use GLEW.
You will also need some math stuff : create a vector ( on the C++ side ), compute your projection matrix... GLM can do that for you.
Last but not least, you may want to use Cg for your shaders (but you can use GLSL instead, which is "built-in" in OpenGL)
Here's the OpenGL SDK site. LINK Is this what you are looking for?
The easy way to tell is if your using glBegin/glEnd statements you using old context methods (good for quick demos and prototyping, bad if your looking to do something that needs to look professional). When you start dealing with opengl topics that cover buffers and hint to VBO- vertex buffer objects and FBOs - Frame buffer objects your in the area of more modern opengl methods. If you want to get up to speed in the shortest amount of time, start with buffers and keep working your way forward. Just remember when your dealing with device contexts (methods to create your windows) if you stick with OGL 2.1 or lower your limiting yourself ( Think roughly DirectX9/early DirectX10) . Your video card handles DirectX10 and OpenGL 3. Best bet start there. Check out NVidia's developer site, http://developer.nvidia.com/ And, take a look at http://opengl.org site check out the forums - http://www.opengl.org/discussion_boards, the guys there are helpful (be careful not to re-post old questions).
Also check out http://swiftless.com - its a good start - and he labels his tutorials by ogl versions.
Does anyone have experience writing professional OpenGL games on Windows? For the Mac, due to apple's control, the OS seems quite "uniform". For windows, due to different hardware, different drivers installed, etc ... the hardware base seems to have many many different configurations.
In theory, OpenGL provides a API that abstracts all this away. In practice, many drivers are often buggy and have weird cases -- has this been a problem for developing games on Windows?
Thanks!
The two biggest GPU vendors (Nvidia and ATI) both provide OpenGL 3.x drivers, which take advantage of the latest features of modern hardware. As Chris points out, the main issue is that the user will need to install the latest drivers from the vendors themselves, as Windows ships with the most rudimentary OpenGL support (thanks to Microsoft, who seem to do everything they can to knife OpenGL and push DirectX). So provided they have recent drivers, you should be fine.
There are inevitably some (mostly minor) differences between the drivers. For example, I've noticed Nvidia's GLSL compiler is a little more picky than ATI's, and rejects some shader code that otherwise works fine. Bottom line is you need to test on both (which you would be doing anyway).
The gDebugger tool seems to be pretty good at tracking down performance issues. (The OpenGL tools that ship free with Xcode are pretty awesome though.)
You'll need to get glext.h from the OpenGL extensions registry and figure out the base requirements for your app. You probably don't want to have alternate code paths based on which extensions are available, if you can help it! And as epatel mentions, there are a few libraries (such as GLEW and GLEE) which help with the process of extension management. I ended up writing my own, as I didn't like those implementations.
There's lots of engines and scene graphs for OpenGL, if you haven't already chosen your toolset.
I've found a few little bugs along the way, but nearly all were easy to work around. These days things are pretty good.
The biggest problem you will face is simply this: Windows 7 does not ship with a hardware OpenGL. If the user does not take the action to replace the default video drivers with updated versions from the vendors site the only OpenGL support they have will be a ~v1.0 software renderer.
I haven't yet made a professional OpenGL game on Windows, but I think one important thing is to query the OpenGL drivers about what capabilities (extensions) are available and handle those functions. There is also a package to handle this in a platform independent way with the GLEW library. Think that is a good start to understand how to handle different OpenGL capabilities.
The OpenGL Extension Wrangler Library (GLEW) is a cross-platform open-source C/C++ extension loading library. GLEW provides efficient run-time mechanisms for determining which OpenGL extensions are supported on the target platform. OpenGL core and extension functionality is exposed in a single header file. GLEW has been tested on a variety of operating systems, including Windows, Linux, Mac OS X, FreeBSD, Irix, and Solaris.