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.
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.
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.
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 about to start working on a custom cross platform engine (c++) that will need to be able to support the latest versions of both OpenGL and DirectX. The renderer is chosen before compilation.
I'm looking at cross platform libraries to handle window creation and input that can also handle the latest implementations of DX and OGL - preferably low profile and most importantly: fast. Any recommendations?
Thanks!
SDL is probably the most used cross-platform library for that kinda thing.
You should check out SFML (Simple Fast Media Library). Although SDL is much more well-known due to its older age, SFML is far richer functionality- and design-wise, despite being only a few years old. It can essentially be described as a newer, more modern, and object-oriented SDL (it's C++; SDL is C).
To give you a brief overview of its features:
Cross-platform (Windows, Mac OS X,
and Linux).
Has modules for system-related stuff
(events, timers, etc), windowing,
video (hardware-accelerated OpenGL 2D
graphics), audio, and networking.
Supports all essential and mainstream
image and audio file formats, with
the notable exception of MP3 due to
licensing issues (although this is
available as an extension).
Also supports fonts (FreeType2 is
integrated) and many other things.
I use it for all my projects that need more than just a command line and I love it. I highly recommend it.
It should be able to provide a good base for your idea.
wxWidgets.
The OpenGL and DirectX are somewhat similar yet very different. OpenGL is built with idea to forward developers desire to render to devices if available. DirectX is built with idea to make rendering capabilities of devices available for developer.
Thanks to differences you end up implementing almost everything twice. Manipulating windows is quite minor issue. You do not need exactly same windows since you will use one or another anyway for rendering in them.
It is perhaps best to use different things for creating the windows (like SDL for OpenGL and MS API for DirectX) and wrap it behind common interface. Then the "things" will be also chosen before compilation. Where MS API is not available there you will lack DirectX too, so no need to make it portable.
Irrlicht
Ogre
Both are fast and powerful. They fit great for games, if I'm getting right your intention.
Can I expect users to be able to run software that uses OpenGL 3.x?
Can Linux users who have open-source graphics drviers run OpenGL 3.x? I know that Mesa3D 7.8 only supports OpenGL 2.1.
I also know that OS X Snow Leopard supports some but not all OpenGL 3.0 features. I don't know the situation on Leopard.
I don't know the situation on XP, Vista, and Windows 7.
I'd like to start learning OpenGL, and my interest lies more in scientific and engineering applications than games. I know I'll be reading code that uses OpenGL 1.x, but I'd like to write code using the newest specification I can expect user's systems to support. I'm wondering whether I should start learning 2.1 or 3.3. I was thinking of getting either the 4th edition of the OpenGL Superbible to learn 2.1 or the 5th edition which is coming out July 30 to learn 3.3. (I have a bachelor's in physics, so my math background is pretty good.)
Edit: I found this related question with answers that are relevant to my question.
As Martin Beckett already pointed out, the situation is really rather bad as far as support for OpenGL 3.x is concerned. Many "modern" graphic chipsets widely used in notebooks (yes, Intel, I'm looking at you) do not even fully support OpenGL 2.x; some even lack features as old as multisampling.
The only way to make your software run on as many systems as possible is to use things like GLEW to decide which features to use at runtime (i.e. no need for conditional compiling).
As far as learning OpenGL is concerned, 2.1 is definitely a good choice, because it enables you to understand both older code using the fixed-function pipeline and more modern code relying on shaders. Afterwards, getting to grips with the most important 3.x features (e.g. frame buffer objects, vertex array objects) will be rather easy.
I can happily inform you that the open source drivers now officially fully support OpenGL 3.0, and Intel will be supporting OpenGL 3.1 as of the next release of Mesa, now renamed to Mesa 9.0. They added official support for OpenGL3.0 as of Mesa 8.0.
The Intel OpenGL support for Windows is currently at 4.0, so that shouldn't be a problem for you.
Regarding AMD and NVidia support, there is full OpenGL4.3 support for both closed source drivers, on both Windows and GNU/Linux. Regarding Open Source drivers, Radeon will officially be bumped to OpenGL3.0 support as of Mesa 9.0, combined with the 3.6.0 kernel release.
It is probably worth mentioning that the drivers supports subsets of OpenGL3.2/3.3/4.0/4.1/4.2/4.3, but the "supported version" can't be bumped until ALL features are implemented. Please see the official document for more detailed information.
These are exciting times for OpenGL!
The Windows XP drivers for Intel's GMA 950 only support OpenGL 1.4, sans GL_EXT_framebuffer_object. Oddly enough on the same exact hardware (a Mac mini) both Linux and OSX manage to support GL_EXT_framebuffer_object.
I don't know the situation on XP,
Vista, and Windows 7.
Bad - most cards claim to support openGl 2.0 or 2.1 but unless they are Nvidia don't expect any features beyond 1.1 to work
IIRC windows vista/7 supports opengl 1.1 in software or 1.4 with a directX wrapper. The graphics driver is free to support whatever it wants but except for Nvidia the quality is poor.
As long as you do only Scientific and Engineering applications, I would suggest you to use Modern OpenGL. Normally an Engineer can afford to buy a Modern Computer with a nice Graphics Card, if he needs it. For Science the application does often only need to run on one Computer, so compatibility with old computers shouldn't be your biggest concern, but being forward compatible with new hardware is never a wrong decision.
Writing a game is very different. Here is it very important to maximize the audience so that you can sell the maximum amount of copies. Requireing too much resources would reduce the target audience very much.