DirectX is more ... um ... standard.
Only if all you care about is Windows. If you want to target linux, MacOS, Android, iOS, etc. then DirectX is useless.
Game Engine Pratical Books
For me, it's Windows and Android.DirectX is more ... um ... standard.
Only if all you care about is Windows. If you want to target linux, MacOS, Android, iOS, etc. then DirectX is useless.
But it's not up to me.
DirectX is more ... um ... standard.
As LennyLen pointed out, DX is only standard to Microsoft (even then it isn't standard). Have you ever looked at AAA games when they install? A lot install using OpenGL rather than DX (even on Windows).
http://en.wikipedia.org/wiki/List_of_OpenGL_programs
http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX (4 years old, but still worth the read).
http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX (4 years old, but still worth the read).
That is the worst pro-GL link to be sharing, such that I can't resist pointing out how densely packed with lies it is... it would take too long to debunk the whole article, so cherry picking a single line:
"On the other hand, if you use OpenGL, you get faster and more powerful graphics features than DirectX 11, and you get them on all versions of Windows, Mac and Linux, as well as the PS3, Wii, PSP, DS, and iPhone."
* OpenGL is faster than D3D9, but much slower than D3D11 (in terms of both CPU-side and GPU-side costs), not faster! Even though it's faster than GL, D3D11 is much slower than it should be, which is why AMD has created Mantle to replace it.
* PS3, Wii, PSP and DS do not use OpenGL; they each use a different proprietary API specific to that device.
* Windows has at least 3 different (and differently-broken) GL implementations, with different performance characteristics - you must test (and rewrite parts of) your code on all 3 implementations to ensure you're on the "fast path" for all three.
* Linux is a clusterfuck of outdated ports of the broken windows drivers, or differently broken open-source drivers.
* Mac is ok, but always lags behind supporting the latest version of the specification.
* iPhone uses GLES 1, 2 and 3... which is so slow and badly specified that they've now replaced it on iOS8 with their own proprietary API.
* Other mobile phones also use GLES as above, but like on Windows, there are umpteen different implementation each with their own bugs and performance pitfalls. You must test (and rewrite parts of) your code for every different device that you want to support.
And one point of my own:
* Each of the 3 Windows implementations contains GL 1, 2, 3, 4, the sub-versions, and vendor-specific extensions. Writing a game that's portable across a range of hardware generations, say GeForce8 to GeForce700 (even if just for a single OS!) requires re-writing parts of your code several times for different versions of the API / different extensions being available. Then when you want your game to be portable across vendors (Intel, AMD, nVidia), you then need to re-write parts of your code again to deal with different breaches of the specification, performance behaviors and available extensions. Then when you want your game to be portable across OS's, you need to rewrite parts of it again. At this point, you've done so much patching of your rendering code for special cases and workarounds, that you really haven't saved any time by using a single "portable" API. You may as well have used one API for Windows, one for Mac, and one for Linux -- it would've taken the same amount of time and effort. Id' argue that having 5 independent versions of the rendering back-end is better than 1 version full of 100 special cases, because the code will be cleaner and easier to maintain.
In fact, this is what most "AAA" games do -- they use D3D9x on Xbox360, GCM on PS3, GXM on PSP, GX on Wii, GNM on PS4, D3D11x on XboxOne, D3D11 on WinVista+, D3D11.1 on Win8+, D3D9 on WinXP, OpenGL 3/4 on Mac, OpenGL 2/3/4 on Linux, perhaps OpenGL 2/3/4 on Windows, GLES 2/3 on mobiles, Metal on iOS8 and Mantle on Win7+AMD!
A 'AAA' might be made up of a million lines of code, but only about 3000 of those actually use the underlying graphics API. That means we're arguing over 0.3% of the code-base here!
Porting a game from one API to another is only a few man-month's of work. Also, once you've learned one graphics API, you can learn another one in just days, because the concepts will be almost identical. So GL portability is just a pipe-dream not a reality, plus it's also just a red-herring because it's not actually an important issue.
David Rosen should be ashamed of that blog post... I don't know why he's never taken it down or published corrections.
That said... this isn't a GL vs D3D thread, so let's not turn it into one 
That said... this isn't a GL vs D3D thread, so let's not turn it into one
Not trying to, in truth, if I broke it into a versus thread it would more than likely be 2D vs 3D as I don't care for OGL nor DX (directly). I prefer the old school 2D games and RPGs over 3D games.
I prefer the old school 2D games and RPGs over 3D games.
With modern hardware you still really need to use either OpenGL or DirectX (for PC at least). Old school techniques don't perform so well any more.
That's why libraries such as Allegro 5 only work on platforms with either of those back ends, unlike Allegro 4 which had a far wider range of platforms supported.
* Linux is a clusterfuck of outdated ports of the broken windows drivers, or differently broken open-source drivers.
Dude, you are my hero xD
Please, come to my country and make a lesson at my Uni XD
..
To remain in topic:
One of my favourite strategy in programming is: take a good book for theory/general stuffs/big picture, and find a good project to use as "inspiring material".
Thank you for confirming my view of it.* Linux is a clusterfuck of outdated ports of the broken windows drivers, or differently broken open-source drivers.
I don't like RPGs (assuming you're referring to that have several modules on the lower/left/right part of screen indicating life, supplies etc. or those you have to press the mouse/touchpad/screen or those that have a weird top view or giant circles on the player) or "old school 2d games" or FPS games.I prefer the old school 2D games and RPGs over 3D games.
I prefer 3d open world games, racing games, simple 2.5d (?) games like temple run and those few like angry birds.
---
1. This book is on my wishlist
Only cons is that it use DirectX so it is not portable on other operating systems.
For 3D Game Engine Programming the author address this within the first couple of pages when he goes over his design for the engine. Since he was using Visual Studio and many readers were most likely on Windows, using DirectX 9 from the start probably made more sense audience wise. If you wish to add in OpenGL right from the start he basically says go for it - there is nothing stopping you. In my opinion DirectX was more of a "proof of concept" using the API classes. Adding any other rendering implementation is rather straight forward using the API independent base class he creates. After adding you're favorite extension, loading and using it takes ~15 lines of code. It is like this for everything in the book such as input, sound, and basic network support.
You should also take into consideration the age of the book in that shader support isn't a highlight of the book so that is something you will have to expand upon yourself. It has a basic shader system but he was targeting 1.0 versions. The FFP is presented only because some graphics cards weren't able to use the shaders. However if you understand the overall idea of the API independent class then adjusting the code won't be difficult.
He also goes into making some simple math classes which was a great learning experience for me. While you could switch over to using another math library if you desire the idea was to teach you more of the core concepts such as matrices and quaternions. The DirectX rendering system makes no use of the D3DX functions but rather the math library implementation - which may or may not help if you want to change to OpenGL. Some SSE is provided in the math library if you are unfamiliar with it, but this can also be adjusted to use something newer if you desire. A simple 3D model format with animation is presented to show you how it is done, but adding support for your favorite format shouldn't be too hard.
One thing to note about the end result of the book - it is mostly geared towards making a small FPS concept with accompanying editor. The editor reminded me of UnrealEd 1.0... just much less... awesome 
. While most chapters can stand on their own regardless of the game, this is just sorta the "glue" to show you that you could make something with everything provided in the book. AI and the actual game are left as practice for the reader.
I hope that possibly clears up any preconceived notions about it being DirectX only and provides a better idea about what the book is about before you buy it. Good luck!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
