Thank you for your reply. I'll consider about that.1. Some people say DirectX has less gotchas and headaches than OpenGL on windows. Some also say OpenGL has worse drivers than DirectX. What exactly are they referring to? Will there be any problems or is there anything I need to be aware if I use OpenGL on windows?
Yes. You can use DirectX directly on windows, while with OpenGL you have to eigther import the DLL commands yourself (don't do it), or use an external wrapper libary like GLEW, to even be able to do anything with it. Also with DirectX you can directly use your created Windows hWnd, while in OpenGL you must configure your window to have a special HDC and use that. Other than that, using OpenGL is not that much different than using it on any other platform (supposed you even write the application creation code yourself and don't use SFML or what not). In any way this is NO reason to use DirectX on Windows if you already have an OpenGL renderer.
2. I hope to support almost every machine, including those very old PC (about 10 years old I guess?) Since I am making a 2D engine, I don't need many advanced features. Is OpenGL ver. 2.0 my best option or should I use a later version?
Recent OpenGL version have a very bad support rate, I know PCs from < 3 years ago that don't even support 3.4 or whatnot. As for features, if you are making a 2D game, there are not that many of use for you anyways. The wikipedia-page on OpenGL has a full list of it, but I don't see what you could really need. For example, I decided to require at least OpenGL 3.1 as they introduced uniform buffer objects which tied in with my pipeline much more (otherwise I'd have to redesign that), but you shouldn't need that. So OpenGL 2.0 should be just fine.
Is OpenGL enough or should I also support DirectX?
Author
Android/iOS don't use GL, they use GL|ES (version 1/2/3).
Desktops use GL (version 1/2/3/4).
Version 1 of both is old enough to forget about.
Also, GL and GL|ES are API specifications, not libraries (API implementations).
There's a lot of implementations of the spec --
On Windows, there's one each from Intel/AMD/nVidia. On Mac and iPhone, Apple has a standard one (GL for desktop, GL|ES for iOS). Linux is similar situation to Windows, but there's also some community/open-source implementations too. On Android, every damn phone manufacturer has their own implementations.
Whenever you have a common specification, but dozens of implementations, someone always fucks up some of the details, or bends the rules, or extends them, or breaks them on purpose.
That's the unavoidable situation for GL (and HTML renderers, or COLLADA exporters, etc).
In a web-page, or a GL renderer, you will end up with some platform/implementation specific tweaks / workarounds / ugly hacks.
The reason this gets brought up in contrast to D3D, is that (each version of) D3D has a single implementation.
Sure - underneath Windows+D3D and under Apple+GL there's another spec (the driver model) which has to be implemented by Intel/AMD/nVidia -- but the difference here is that there is a gatekeeper. MS/Apple can test driver implementations and reject ones that fail to comply with the spec. This means that D3D+Windows and GL+Apple tend to be very stable and correct, but GL on Windows/Linux have no guarantees, and GL|ES on Android is a clusterfuck.
Desktops use GL (version 1/2/3/4).
Version 1 of both is old enough to forget about.
Also, GL and GL|ES are API specifications, not libraries (API implementations).
There's a lot of implementations of the spec --
On Windows, there's one each from Intel/AMD/nVidia. On Mac and iPhone, Apple has a standard one (GL for desktop, GL|ES for iOS). Linux is similar situation to Windows, but there's also some community/open-source implementations too. On Android, every damn phone manufacturer has their own implementations.
Whenever you have a common specification, but dozens of implementations, someone always fucks up some of the details, or bends the rules, or extends them, or breaks them on purpose.
That's the unavoidable situation for GL (and HTML renderers, or COLLADA exporters, etc).
In a web-page, or a GL renderer, you will end up with some platform/implementation specific tweaks / workarounds / ugly hacks.
The reason this gets brought up in contrast to D3D, is that (each version of) D3D has a single implementation.
Sure - underneath Windows+D3D and under Apple+GL there's another spec (the driver model) which has to be implemented by Intel/AMD/nVidia -- but the difference here is that there is a gatekeeper. MS/Apple can test driver implementations and reject ones that fail to comply with the spec. This means that D3D+Windows and GL+Apple tend to be very stable and correct, but GL on Windows/Linux have no guarantees, and GL|ES on Android is a clusterfuck.
If you're fine with fairly old rendering techniques (no constant buffers, just shader uniforms, no VAO's) I wouldn't call OpenGL 2.0 or 2.1 bad. It has a fairly straightforward mapping to OpenGL ES 2.0, meaning your rendering code won't differ that much between desktop & mobile, and because it's older, it's better guaranteed to work with older drivers. You'll just need to be strict with obeying even the "stupid" parts of the specs, like for example if you use multiple render targets with a FBO, make sure they are the same color format.
If you use only GL ES 2 you can try use https://code.google.com/p/angleproject/ to get the benefits of D3D (consistency/stability) without using it yourself.
I've never tried it myself, but if it works for Chromium itself it must be good enough.
Id tech is one notable AAA company that uses GL, but that is largely historical.
Some/most graphic engines abstract away GL/D3D part into a common API so you mostly don't care about which one is running, and this is what any sane engine should do so rest of the code is both independent of that and not trashed by GLuint and other fun types and macros being in the headers and the API.
Doom 3 BFG actually used 3 APIs: one for PS (Sony's NDA low level one), one for XBox (DirectX) and one for Windows (GL), they too wrapped them in common API in own code while original Doom 3 was PC only with GL only.
A frequently-overlooked issue is tools support. Direct3D has fabulous tools. OpenGL has mediocre tools. When it comes to debugging why nothing's rendering, or why buffers seemingly have the wrong value, or why your shaders aren't doing what you expect, those tools all come in extremely handy. I highly recommend writing all your initial code in Direct3D and then - once you know your code is correct and working properly - porting it to GL afterwards. If you are smart and abstract your drawing code (nothing but the renderer itself should ever touch D3D/GL) then porting is often something you can do in a few days for most indie/hobby games.
So far as portability, GL is also an incomplete story. Some OSes force you to use GLES, some force you to use GL Core to get modern features, some OSes still have stone-aged drivers, some platforms are pushing new proprietary APIs and potentially abandoning GL, some platforms have never had GL in the first place. If you care about maximum portability or just learning how to do graphics like The Pros, you need to accept that you need multiple backend renderers that target different APIs. Or even more confusingly, that target the same API but with wildly different feature sets (GL 2 vs GL 4, mobile vs desktop use of GLES/WebGL, etc.).
So far as portability, GL is also an incomplete story. Some OSes force you to use GLES, some force you to use GL Core to get modern features, some OSes still have stone-aged drivers, some platforms are pushing new proprietary APIs and potentially abandoning GL, some platforms have never had GL in the first place. If you care about maximum portability or just learning how to do graphics like The Pros, you need to accept that you need multiple backend renderers that target different APIs. Or even more confusingly, that target the same API but with wildly different feature sets (GL 2 vs GL 4, mobile vs desktop use of GLES/WebGL, etc.).
To echo Sean... As an example many newer programmers don't know how or what kind of images should be loaded from disk. With DirectX there's some convenient functions for loading (for example) PNG files without using zlib/pnglib, so it's largely a non-issue when using DX. With OpenGL all images will need to be loaded with some additional code since no utility functions are given by GL.
As an example many newer programmers don't know how or what kind of images should be loaded from disk. With DirectX there's some convenient functions for loading (for example) PNG files without using zlib/pnglib
Not just that, but in DirectX there is the dds format which can hold texture arrays, texture cubes, mipmaps, and all sorts of other stuff in one convenient container format. For directx definitely investigate it...
Not just that, but in DirectX there is the dds format which can hold texture arrays, texture cubes, mipmaps, and all sorts of other stuff in one convenient container format. For directx definitely investigate it...
You can use it with GL too; it's only a container format and the data payload is the same whatever graphics API you are using.
Really .dds should be your first stop when loading game ready textures, it can handle everything you graphics card can after all.
PNG and TGA are source images and shouldn't be anywhere near your final game.
You can use it with GL too; it's only a container format and the data payload is the same whatever graphics API you are using.
Yes true, the down side is that outside of windows you'll need a third party library to load dds files or its a case of roll your own. It's a feature rich format which I wouldn't fancy creating a parser for myself. Best to stick to windows for that IMHO and leverage that particular advantage...
Since vulkan is coming out, DirectX will probably become obsolete. You can also do anything in DirectX in OpenGL + extensions. It's just not as easy.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
