• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
  • entries
  • comments
  • views

Direct X vs OpenGL revisited... revisited.

Sign in to follow this  
Followers 0


A short time ago David over at Wolfire posted a blog entry detailing why we should use OpenGL and not DirectX.

The internet, and indeed, his comments asploded a bit under that. I posted a few comments at the time but didn't revisit the site afterwards, mostly because it wouldn't keep me logged in and the comment system was god horrible.

The comments could be split up into the following groups;

- MS haters who want everything they touch to die, largely OSX and Linux users.
- OSX and Linux gamers who, despite not having any technical background, have decided that OpenGL is 'best', for mostly the same reasons as the above.
- Die hard OpenGL supporters, who believe that DX and MS are terrible but offer no technical details as to why.
- Die hard DX supporters who were just as bad as their OpenGL counterparts.
- A few people with both the technical opinion and experiance to back up what they were saying - the only bit of signal in alot of "fanboi" noise.

In a way it was sad to see this as this could have been a good chance to thrash out a few things.

David has since made a follow up post to address some of the arguments made, and while a bit more balenced still shows a slight anti-MS "I'm the only one who can see the truth" bias to it.

However, we'll come to that post in a bit, firstly I want to cover the inital post, which I meant to do at the time but never got around to it.

Before I go on I'd like to make a point or two to clear up my 'position' if you will;
- For those who have been around the site for a few years you'll know that I was the OpenGL forum moderator for some time and was heavily involved in that subforum.
- I've also written two articles on OpenGL for using the (at the time much misunderstood) FBO extension and I've had a chapter published in More OpenGL Game Programming regarding GLSL.

In short I'm not someone who grew up on DX and who lived and breathed MS's every word about the API. I spent some years on the OpenGL side of the fence "defending" it from those who use D3D and attacked it, both on the forums and on IRC. Its only in the last year and a half or so that I've dropped OpenGL in favour of D3D, first D3D10 then D3D11, so I've over 4x more years using OpenGL than I have D3D.

Why you should use OpenGL and not DirectX

The opening of the blog somewhat sets the tone, overly dramatising things and painting a picture that 'open is best!'.

It opens by saying they are met by 'stares of disbelief' and that 'the temperature of the room drops' when they mention they are using OpenGL. As I said, dramatic and I feel the first question is a valid one.

If someone said to me 'I plan to make a game, I plan to use OpenGL' I might well act surprised and at the same time I would ask the important question; Why?.

Not 'why opengl?' but why this choice; what technical reason did you have to decide that, yes for this project OpenGL is the best thing for you. If the answer comes back as 'we plan to target Windows, OSX and Linux' or mentions either of the latter OSes in a development sense than fair play, carry on you've made a good technical case for you.

Which is somewhat the key point here; the title suggest that everyone should use OpenGL over DirectX. Not 'use it if its technically right' or 'because our development choice requires it' but because you just should. It then goes on to try to explain these reasons, with a bias I considered quite intresting.

The technical case is a good place to start, because in that inital article he starts off by attacking anyone who 'goes crazy' over MS's newest proprietary API.


What kind of bizarro world is this where engineers are not only going crazy over Microsoft's latest proprietary API, but actively denouncing its open-standard competitor?

To which I have to say this; what kind of bizarro world would it be if engineers ignored the best technical solution for them in favour of one which doesn't fit it just because the one which does is 'open'?

This, to a degree, is part of my problem with the whole inital piece; it paints those who us DX as mindless sheep; people who are woed by shiney presentations and a few pressed hands at a meeting. Maybe some are, in much the same way that many people who use OpenGL do so because 'MS is evil'.

But, any true self respecting engineer or designer would look at things like this, look at the alternative and see how it fit their use case. MS reps could press hands all they want, but if someone goes away, tries it and it sucks... well, it won't catch on.

The History

There are only "minor" factual errors here, the main one painting a picture of OpenGL being on every things out there apart from the XBox. That last bit is true, the XBox doesn't expose OpenGL to the developer (nor is its D3D strictly D3D9) but everywhere?

Firstly, OpenGL|ES is not OpenGL. There are differences in both feature set and the way you would program the two APIs. As much as I'm sure people would love to be able to write precisely the same code for both your desktop and mobile device the reality is there are still differences. OpenGL and OpenGL|ES are working towards unity, but it isn't there yet.

OpenGL also isn't on the Wii or PS3. Well, the PS3 does have an OpenGL|ES layer but its slow and people just goto the metal. The Wii has an OpenGL-like fixed function interface, however the functions are different as it coding it.

So, in reality, OpenGL has Windows, Linux and OSX.
And yes, I won't deny that is more than the windows you get with just raw D3D (although XNA does tip things again).

I'm not going to argue numbers, I'm not market analysis or business man, I'm just correcting some facts.

Why does everyone use DirectX?

The first section of note, because there is nothing really in the 'network effects' section worth talking about is the 'FUD' section.

This, predictably, centres around Vista and the slide which, apprently, shows that OpenGL will only work via D3D. He even links to an image here and the HEC presentation to prove the point.

Amusingly both show his point, and indeed the point of the OpenGL community to be wrong; if there was any FUD then they cause it themselves.
Now, I was about at the time, when I first heard the news I too was outraged at the idea, there may even be a few posts by myself condeming things, so I was taken in by some negative spin as well.
The problem is lets really really look at that image; see the 'OpenGL32/OGL->D3D' box? See the line going from that top 'OpenGL32' section to 'OpenGL ICD'? Yep, that's right.. the OpenGL subsystem was always linked to the OpenGL ICD, an IHV-written segment of code.

So, if there was any FUD it was caused by an over reaction to a non-event; an over reaction NOT caused by MS but by the community itself. Talk about shooting youself in the foot; if anyone hurt OpenGL that day it was, ironically enough, those who liked it the most.

The misleading marketing campaigns... well, I still feel this is a bit of 'he said, she said'. DX10 did bring some new things to the table but it never really got much of a true run out to decide either way due to how Vista was greated. However the one thing to come out of all of this was that D3D9 games stuck around, no one jumped on D3D10 but I feel this is less of a problem with the API than the OS it was tied to.

Finally, there is the old favorite in any OpenGL vs DX debate; The John Carmack quote.

In a way I feel sorry for him because ANYTHING he says re:graphics gets jumpped on as 'the one true way' and a big thing gets made out of it by any camp who can use it to their own ends.

The quote in question is;

"Personally, I wouldn't jump at something like DX10 right now. I would let things settle out a little bit and wait until there's a really strong need for it,"

The problem is, the quote is missing context;


John Carmack, the lead programmer of id Software and the man behind popular Doom and Quake titles, said he would not like to jump to DirectX 10 hardware, but would rather concentrate on his primary development platform - the Xbox 360 game console.

"Personally, I wouldn't jump at something like DX10 right now. I would let things settle out a little bit and wait until there's a really strong need for it," Mr. Carmack said in an interview with Game Informer Magazine.

This is not the first time when Mr. Carmack takes Microsoft Xbox 360 side, as it is easier to develop new games for the consoles. Mr. Carmack said that graphics cards drivers have been a big headache for him and it became more complicated to determine real performance of application because of multiply "layers of abstraction on the PC". The lead programmer of id Software called Xbox 360's more direct approach "refreshing" and even praised Microsoft's development environment "as easily the best of any of the consoles, thanks to the company's background as a software provider".

"I especially like the work I'm doing on the [Xbox] 360, and it's probably the best graphics API as far as a sensibly designed thing that I've worked with," he said.

And thus the reason becomes clear; its not because he loves OpenGL but because he prefers working on the XBox right now and finds the API, the one very much like D3D9 (although with some differences), "refreshing".

The usage of the original quote to try to prove a point is misguided at best, dishonest at worst.

At this point you could point at 'Rage' and say 'ah, but that is in OpenGL, therefore OpenGL MUST be better!'. However any such claims fail to take into account the years of work iD have done with OpenGL, the tools they have, the code base they have AND the technical requirements; as a proper engineer should.

Finally, we get down to the 'meat' of the main article, and this is where technical accuaracy takes a bit of a dive;

So why do we use OpenGL?


... in reality, OpenGL is more powerful than DirectX, supports more platforms, and is essential for the future of games.

Now, more platforms is true, I've covered it already and it can't be argued with, the other two statements however are an issue...

OpenGL is more powerful than DirectX

Well, we'll ignore the poor phrasing as DirectX is much more than OpenGL just from API weight alone, so lets focus on the "facts" presented.

So, D3D9 has slower draw calls than OpenGL; this is true on XP. No one is going to dispute this fact and it is down to a poor design choice of having the driver transition to kernel mode for each draw call. This is practically the reason 'instancing' was invented, and while it was invented to get around the cost of small object draw calls it did also open up some intresting techniques. OpenGL, while being faster for small object draw calls, lacked this feature. People asked for it, it didn't turn up until OpenGL3.x in any offical version (NV might well have had an extension for it before then but that's hardly the same as cross vendor support).

The thing is, that was XP, Vista changed the driver model to remove this problem and it no longer exists in a modern OS. It's still a consideration if you are doing D3D9/XP development but going forward is simply isn't an issue. More important is the need to reduce your draw calls to stop burning CPU time on them anyway.

This brings us nicely to the issue of 'extensions'.

Even when I was developing with OpenGL I viewed these as a blessing and a curse; ignoring the need to access them via a trival extension loader there was the issue of cross vendor support.

It's no secret that until recently ATI/AMD's OpenGL support was spotty. They didn't support as much as NV did and often lagged behind on newer versions. While I personally developed on an ATI machine this was still a source of annoyance at times (such as the slow appearance of async buffer copies from an FBO to a VBO via a PBO which appeared first in their Vista driver some time after NV's own effort.) even if I did manage to miss most of the bugs.

So while they do allow access to newer feature sets there is the cross vendor cost to pay; the choice if this is an advantage or if D3D methods of capbits (D3D9), fixed functionality (D3D10.x) or 'feature levels' (DX11) suits you better is a personal choice.

D3D also had a rudimentry extension system; ATI mostly included some 'hacks' you could perform to do special operations; such as hardware instancing on older cards and render to vertex buffer directly. These few features have the same 'cross vendor' cost as above however.

At which point we get to some down right incorrect 'facts' surounding tesselation.
The main one was;

The tesselation technology that Microsoft is heavily promoting for DirectX 11 has been an OpenGL extension for three years

Unfortuntely this is pretty much all wrong. The extension in question, provided only by AMD due to NV currently having no hardware which can do it, didn't appear in the public domain until last year. I know this because I was watching for it to see when it would finally make an appearance.

The other problem is that it is NOT the same thing; D3D11's tesselator consists of 3 stages;
- hull shader
- domain shader
- tesselation

This extension provides the 3rd part but not the other two. Right now, looking at the extension registry, I see nothing to indicate OpenGL supports these features, nor do I believe it will until NV get Fermi out of the door (May this year?) and have their own extension.

There is also this assertion;

I don't know what new technologies will be exposed in the next couple years, I know they will be available first in OpenGL.

This is nothing more than hand wavy feel good nonsense and is easy to disprove; where is OpenGL's Hull and Domain shader support? More importantly, on the subject of 'power' where is OpenGL's support to have 'N' deferred contexts onto which I can build "display lists" from 'N' threads and have them draw on the main thread? Or the other multi-thread things D3D11 brings to the table? Multi-core is the future, even if your final submit has to be on a single thread the ability to build up your data in advance is very important right now.

Finally, based on recent history and the way things are going MS are driving the tech now; if it continues as it is then the ONLY ways OpenGL is going to get a feature before a D3D version does is if the ARB stop playing 'catch up' with the spec and get a GL version ahead of D3D OR a vendor releases a card before a D3D release with OpenGL exension ready to go.

That point also goes hand in hand with the comment about 'the future of games'.
There are two things are work here which go against that statement;
- Firstly OpenGL hasn't been a threat to D3D for some time. D3D has been driving development of hardware forward while the ARB seemed to flounder around arguing internally. They have got better of late, but they are still behind.

- Secondly; consoles. They have the numbers and they are significantly easier to develop for. They are the driving force behind the big games at least and to a degree influence what those coming behind want to do.

Don't get me wrong, I wouldn't declare PC gaming to be 'dead' but it is very much a second fiddle these days.

The finally arguement put forward in this section is that 50% of users still have XP systems; yep can't fault that either, the Valve hardware survey which it was linked to does indeed back this up and this is a fine number to cling to if you are releasing a game now or maybe even in the next few months. However there is a reality here which it ignores; Windows 7.

The uptake of Windows 7 has been nothing if not fantasic, certainly after Vista's panning, and this is a trend expected to continue as new PCs come with it and gamers, seeing a 'proper' update from XP move across to it. If only half of those on XP with a DX10 card move across to Win7 then people who can run D3D11 based games, all be it on the D3D10 feature level, will 63% and I would suspect this will be true in reasonably short order. In short; if you are starting a game now to be released in a year or two then there isn't a good reason NOT to use D3D/DX11 based on those numbers (provided you are targetting only windows of course).

OpenGL is cross platform

Yep, agreed, although again we find a Carmack quote pulled out and then twisted to spin positive for OpenGL usage;

As John Carmack said when asked if Rage was a DirectX game, "It's still OpenGL, although we obviously use a D3D-ish API [on the Xbox 360], and CG on the PS3. It's interesting how little of the technology cares what API you're using and what generation of the technology you're on. You've got a small handful of files that care about what API they're on, and millions of lines of code that are agnostic to the platform that they're on." If you can hit every platform using OpenGL, why shoot yourself in the foot by relying on DirectX?

Again, the final assertion ignores the tools and existing tech iD have when dealing with OpenGL which makes it a viable choice for them, it also seems to ignore that they target D3D-ish for the X360 and the native lib for the PS3. Also, as pointed out earlier, OpenGL doens't get you 'every platform'; more than D3D, yes, however it then goes on to point out that XP users are the biggest single desktop gaming platform and with the migration to Win7 well underway it becomes less cut and dry.

OpenGL is better for the future of games

This... well, it reads more as an attack on MS than anything else. Talk of monopolistic attack and an 'industry too young to protect itself' is nothing more than a plea to the heart than a fact based arguement... so lets bring in some facts!

The 'attack' spoken of here would seem to speak of the FUD section earlier, but there are two problems with that.

Firstly, as I pointed out, the FUD over Vista was self inflicted. The community did it to themselves and yet somehow MS got the blame.

The second is the idea that programmers and engineers would use something just because someone showed them some pretty slides and said 'hey, use this' without taking the time to look into it. If D3D didn't deliver then no one would touch it outside of the Xbox, indeed if it hadn't then something else would have come up or the XBox wouldn't have existed in the first place.

Then there is an "industry too yong to protect itself"; the industry isn't that young.
I was playing games back when I was 5 years old, thats 25 years ago. The Atari 2600 was released in 1977, 33 years ago. The industry has been here for over 30 years, over many platforms so the idea that it is 'young' and undefended is strange. If anything programmers are one group who are, tradionally, very resistant to change, doing things they way they did back in the old day because it was good enought then. So for them to switch to D3D from OpenGL means there must have been a good reason.

And there is something which is rarely pointed out; OpenGL was indeed there first. Granted, for 3D acceleration it was beaten out by GLIDE initally with many games supporting it, however as the ICDs appeared games started to move across to OpenGL and away from GLIDE. Half-Life and Unreal Tournament stand out as two games which had GLIDE, OpenGL and D3D support with D3D being the less choice in those days.

In short, it was OpenGL's position to lose and they lost it. MS might well have had a hand in this when they were on the ARB (I don't know for sure) but they left in 2003 and yet nothing happened.

Which brings us to, what was for me, the highlight of the blog in the final section;

Can OpenGL recover?

Firstly, I would say yes it can, but it will need the features, cross vendor and the tools on windows and better support. It will need to give people a reason to switch away from D3D11 (or whatever follows).

However, this isn't the key bit as among the tugs on the heart strings and the 'exists only to stop you getting games on XP, Mac or Linux' rant there was this little gem;


If there's anything about OpenGL that you don't like, then just ask the ARB to change it -- they exist to serve you!

This gave me a few minutes of laughter for a good reason; experiance has taught me that the ARB couldn't find its own arse with 4 tries and a detailed map.

Infact this is a good entry point into the follow up article as well...


OpenGL 3.0 sucked! It was delayed drastically and didn't deliver on its promises!
OpenGL 3.0 was not the revolutionary upgrade that it was hyped to be, but it was still a substantial improvement. OpenGL 3.1 and 3.2 addressed many of the concerns not addressed by 3.0, and it looks like it's on track to keep improving! If more game developers start using OpenGL again, the ARB will have more incentive and ability to keep improving OpenGL's gaming features.

And between the two here in lies part of the problem.

Developers, including game developers, were presented with a much improved and above all modern API by the ARB. They told the ARB they loved the direction, gave feedback and generally made a big noise about looking forward to it; after the mess which was OpenGL2.0 and the amount of time it took to get VBOs it finally looked like D3D10 had given them the kick they needed.

You see, D3D10 has been hailed as a great improvement to the API; its usage fell flat due to Vista, however D3D11 is very much a slight refinement of it. Longs Peak was in the same manner, indeed it was better than D3D10 based on what little we had seen.

The ARB talked, we said 'awesome!' and then... well.. I don't know if we'll ever truely know.

It went silent, people asked for updates, nothing happened and finally, after a wall of silence had decended OpenGL3.0 was released and the Opengl.org forum asploded. Yep, they had done it again.

This is the problem with OpenGL and the ARB; they do it to themselves.

On the day OpenGL3.0 was announced numberous people, myself included, made a noise and then walked off to D3D10 and D3D11 land. Much like the FUD problems before the OpenGL community had crippled itself.

I know from a few PMs I had at the time there were people who worked on the Longs Peak spec who were just as upset about this turn of events.. well, more so.. than the end users who walked away. As I said I doubt we'll ever really know, all I do know is that, despite what went around at the time, I was told it wasn't the CAD developers who caused the problem.
(Personally, I think Blizzard and one of the IHVs sunk it... but again, we'll probably never know).

All of which brings me back to the two quotes above; the ARB have shown time and time again they can't get things done. MS, on the other hand, deliver. Between that and the tools, docs and stability of the drivers I know whos hands I'd rather put my future in.


Are you saying that AAA developers use DirectX just because they're too stupid to see through Microsoft's bullshot comparison ads? You're the only one who's smart enough to figure it out?
No, of course not. That kind of marketing primarily affects game developers via gamers. Since gamers and game journalists are not graphics programmers, they believe Microsoft's marketing. Then, when the gaming press and public are all talking about DirectX, it starts to make rational short-term business sense for developers to use DirectX and ride Microsoft's marketing wave, even if it doesn't make sense for other reasons.

On the other hand, game developers are directly targeted by DirectX evangelists and OpenGL FUD campaigns. At game developer conferences, the evangelists are paid to shake your hand and deliver painstakingly-crafted presentations and well-tested arguments about why your studio should use DirectX. Since nobody does this for OpenGL, it can be hard to make a fully informed decision. Also, not even the smartest developers could have known that the plans for dropping OpenGL support in Vista were false, or that the terrible Vista beta drivers were not representative of the real ones. It doesn't leave a bad taste in your mouth to be manipulated like this? It sure does for me.

Are these the only reasons why DirectX is so much more popular than OpenGL? No, but they're a significant factors. As I discussed at length in the previous post, there are many network effects which cause whichever API is more popular to keep becoming more popular, so small factors become very large in the long run.

I somewhat covered this earlier, but I feel its worth addressing this directly.

The first paragraph is certainly true now; gamers do talk alot more about D3D however it wasn't always the way. At one point OpenGL was the big name, not as big because it was a few years back now and the internet wasn't as connected as it is now, but it was still a major factor. For some years it was always a belief that OpenGL games looked better and I recall the asplosion which occured when it turned out Half-Life 2 wouldn't support OpenGL.

Which brings up two points;
- OpenGL was popular, yet it lost it before the "fanboys" and gamers had latched onto D3D
- Developers were already switching across to D3D only at this point, before the marketing factor which exists today kicked in

That alone tells us something about the fight between OpenGL and D3D on a technical merit.

The second paragraph seems to, yet again, cast doubt on the ability of other engineers to make a technical choice. Again, we need to view this with some history attached; before D3D9 DX wasn't really a 'big deal', DX7 sucked and DX8 wasn't better. MS, while putting cash in, wouldn't have been putting anywhere near as much in and, due to its popularity, OpenGL would have had a high share of technical knowledge; many people back in 2000 wanted to work with OpenGL simply because they attached the name Carmack to it.

Again, this was OpenGL's position to lose.

The final section about the FUD and beta drivers seems to also continue this theme of engineers and developers being naive.

The FUD is somewhat forgiveable for the younger engineers and those who didn't look at closely to start with; someone misread something, a shit storm appeared and hurt OpenGL but not from MS as already mentioned. In fact, I dare say most developers who took the time to look (including myself after a while) would have realised no such dropping of OpenGL was going to happen.

As for the beta drivers... well; read your release notes.
No one should expect 'beta' to be final quality and, ATI at least, pointed out they didn't have any OpenGL drivers. I have a vague memory that NV made a point of saying they weren't final as well but I wouldn't swear to it.

Given this situation I feel it is David who in his reply is trying to maniplate the reader into something which, when looked at more closely, never happened or was never really a problem if people had thought about it. So, yes, it does leave a bad taste in my mouth when someone tries to repaint the past and manipluate me.

As for the rest of the reply, well he does do a decent job of being more honest and less evanglical than before;

- While he points out that you might not want OpenGL if you are doing a console exclusive or XBox game with a cheap windows port I disagree with the assertion that in other cases OpenGL is the logical place to start. Technically speaking D3D11 is the better API, it is cleaner and offers more features, but beyond that there is the issue of what you want to do; even if you are just developing for a home computer that doesn't mean you'll want to support OSX or Linux; with that consideration OpenGL isn't the logical choice although it is still a choice.

For me it wouldn't be, which is an example of technical thinking; I want to push cores to the limit and OpenGL just doens't have that multi-threaded support that D3D11 does; this is a technical barrier and only D3D11 can support what I want to do.

Infact this links into this statement;

If we take a larger view, the core functionality of Direct3D and OpenGL are so similar that they are essentially identical

To which I disgree; depending on the level of support and what constraints you are under (such as above) there are large difference between Core GL3.2 and DX11.


The most important differences are that one is an open standard, and the other proprietary, and that one works on every desktop platform, and the other does not.

Frankly, the first statement is rubbish; open standard vs propritary doesn't matter if one can do things the other can't. The second statement only matters if it dovetails with your plans, which may or may not be restricted by technical reasons.

After that it is mostly minor issues, a retraction on tesselation, all be it with a down play of the tech and saying OpenGL will be ready when it is important/popular (AvP would like to have a word with you about that one), which while nice doesn't really help developers get on and use it. He does also say that older methods can produce the same visable result as the older methods, which might be true however speed is an issue here and I doubt it'll be as fast (less so on Fermi as it can tesselate 4 triangles at once via a change in hardware). He questions the fixed function stage. ignoring the two programmable stages around it it seems and also ignoring there is no need for it to be programmable given its nature. It might well become more programmable in future, although I'm not sure how, but this is a sane stepping stone if that is the case. Finally a comment about ATI having tessleation for a decade but not being used, for good reason;
- Tru-form wasn't great
- The tesselator on the 360 wasn't great either
- The tesselator in the consumer cards wasn't exposed until last year

By contrast D3D11's setup has 1 game out using it (Dirt2) and AvP coming soon which makes heavy use of it with other games sure to follow.

And I think that covers all the important points.

As I hope you can see things aren't a cut and dried as some would like you to believe; D3D didn't muscle out the little guy via funding and FUD. The little guy was once the big guy and simply lost because it didn't improve and because it generated its own FUD.

So, to reformat and ask the original blog's question again I think would be a good way to end;

Why should you use OpenGL?

You should use it when it meets your technical demands.

But please; try to leave emotion at the door, its just an API after all, no need to try and tug at the heart strings.

Sign in to follow this  
Followers 0


Very nice read, refreshing to see a balanced and well-strucured article on this apparently very touchy subject!

Share this comment

Link to comment

All kidding aside, a fantastic article. Really well written and makes great arguments on an increadily inflammatory subject.

Share this comment

Link to comment

All kidding aside, a fantastic article. Really well written and makes great arguments on an incredibly inflammatory subject.

Share this comment

Link to comment
Very well said indeed!

I guess it really comes down to using what tool is best for you at that time and situation.

Share this comment

Link to comment
One of the aspects of this that I find interesting is the play that mobile devices will have on this long time battle. Apparently, DirectX is not coming to Windows Mobile 7 and with Apple trumpeting how you can build applications for the iPad and for the iPhone using the same "API", no DirectX on a mobile device seems like a mistake. OpenGL however, is implemented in Windows Mobile 6.* and will be part of 7.* so OpenGL seems to have been given another lease on life in the world of mobile 3D games.

Will they take advantage of it? If they don't Microsoft will make sure DirectX is on a mobile platform so that their games on Windows Phones can compete with the games on the iPhone.

Share this comment

Link to comment
Honestly, I see all those arguments, counter-arguments, counter-counter-arguments, ad infinitum, as a waste of energy and brain cells. It's tiring, and useless. I just don't see any point at all to this. It's not like anyone is going to waste his time learning either OpenGL or D3D. There's no wrong choice. Whatever he chooses, even if he's been misguided by 'X is better than Y' articles, in the end he'll learn a useful API, and that's what matters.

I don't even agree with the 'choose the best tool for the job' thing. What is *really* the difference between OpenGL and D3D, aside of course from the occasions where one of them is simply not available on the platform in question? At different times, one has slightly more features than the other, and vice versa, but overall they're the same damn thing, they stand in the same level between the programmer and the hardware, they expose the same functionality. If the card is capable of something, then sooner or later, both APIs will support it. It has always been like that, and there's no reason to think it will change. Obsessing over who gets the newest shiny feature first seems like a pissing contest. Especially with the rise of fully programmable GPU, CUDA,Compute Shaders,OpenCL, whatever. I'm all for making intelligent conversation about what can be improved in both APIs, but this 'VS' thing, I simply don't get it. The post was intelligent and well thought-out, but I think the topic is just not worth it. Anyway...

Share this comment

Link to comment
So, D3D9 has slower draw calls than OpenGL; this is true on XP. No one is going to dispute this fact and it is down to a poor design choice of having the driver transition to kernel mode for each draw call.

This is the second time I see this misconception on this forum in a week :

There is not one kernel mode transition for each draw call. It would be prohibitive to do so. The draw calls and state changes are batched together so that there is only one transition for "a lot" of state changes and draw primitives calls. This has been existing for years.

If people are interested it's covered in the IHV doc for example :
D3dDrawPrimitives2, is the main function, its arguments are a set of dp2commands (see the list of operations here)

The reason perf per batch is limited is mostly because of heavy state management. And because d3d9 is quite more complicated than d3d10 (at first at least..), state management there is also more heavy.

Share this comment

Link to comment
I just wanted to say bravo, I seldom get a reason to come out of hiding on gamedev.net, but you've pretty much tackled everything I felt was wrong about Davids post on OpenGL in a clear and neutral manner. Thank goodness someone did.

Share this comment

Link to comment
I've been using OpenGL regularly and in production for a decade, and I've been following Direct3D's developments pretty closely.. and although it may appear I'm on the OpenGL side of the fence, I also believe David's article is bullshit.

OpenGL and Direct3D have identical features

Not really. For example, Direct3D has this nice, essential feature where you can dump shader bytecode to disk to cache your shaders. There's no such thing in OpenGL, meaning that you have to recompile/link all your shaders at run-time. A friend of mine had a demo with an uber-shader that took one minute to compile. Every. Time. A good incentive to switch to D3D.

The OpenGL extensions mechanism is both a blessing and a curse. It's nice for experimenting in your personal projects/demos/prototypes, but in "real" production code, you're most likely not going to re-implement a feature 3 times (once when the ATI versions pops up, once when the NVidia versions pops up.. and a few years later, when the ARB/EXT version finally arrives). So you'll be waiting for the "common" version, and given the reactivity of the ARB, you may as well wait many years.

According to David, OpenGL gets features sooner than D3D. Well, it's kindda true in theory, but in reality.. remember what happened when VBOs were introduced. They were already available in D3D9, but we had to wait how long exactly ? .. to have a stable and mature version that everybody could use in OpenGL ?

It's the same situation today with the tesselation. It's available right now in D3D11. It may not be available on NVidia cards yet, but if I use the tesselator feature in D3D11, I have the insurance that my code will run "as is" when NVidia will finally release cards supporting it.

If I wanted to do that today in OpenGL, I'd implement it 3 times; first, the ATI/AMD version, right now. Then in a few months, when NVidia releases its Fermi cards and its own extension. Then, a third time in 2-3 years when the tesselation feature will get integrated into the core. Sorry, but I have no energy/time to waste to reimplement it 3 times.


Share this comment

Link to comment
Great read!

Back then I was waiting for Longs Peak (I've always been a D3D user) because I liked the idea of a renewed API, cross-platform, object oriented, and full featured.
I was particularly annoyed DX9 didn't expose some DX10 functionality that could have been exposed (say, "DX 9.0d" instead of 9.0c); specifically reading from the depth buffer as a texture. A different driver model was no excuse for not exposing this critical capabilities in D3D9.

But then the ARB ruined it again.

I'm using Ogre, so I try to keep compatibility across both rendersystem plugins (D3D9 & OGL), but my main target still remains D3D9, why?:

* I'm annoyed of ATI driver bugs
* Some GLSL shaders don't compile on some drivers. NVIDIA is too relaxed on the specs, ATI doesn't do it well. Forget about Intel.
* A few days ago I used a Cg script with the vp40 profile, guess what? For some reason it got broken if I used constant register indexing from vertex attributes. Luckily I found a workaround (changed to the simplest profile that worked) after loosing countless hours to find out my shader was fine.
* I'm still waiting for MRT support where you aren't force to use all FBOs of the exact same format. Stupid limitation that wasn't even present on early SM 2.0 cards.
* NVPerfHUD ROCKSS! (can't use that with OpenGL)
* When I turn DirectX debug runtimes on, they tell me exactly what I'm doing wrong with tons of warnings. Where's the OpenGL counterpart? (tip: has to be free to compete)
* I particularly find OpenGL's documentation horrible. It's just a list with bunch of calls, a little explanation; and if you want an in-depth explanation go to the specs, which can be up to 10-page txt file. Then it throws you out of nothing some samples as source code, which you have to keep looking and collecting around the web.
Direct3D documentation is well presented, full of images, tutorials with very advanced topics, an explanation of what each sample does; discussions of the drawbacks of each feature (or even other topics like x64 support) on different HW.
For example, I couldn't find anywhere in OGL if there's a way to share the backbuffer's depthbuffer for FBOs? (and vice vesa). So far I've only found a non-official wiki which states:

Can you bind the main framebuffers depth buffer as a depth buffer for your FBO?
Does GL 3.0 allow using the main depth buffer? Unknown.

"Unknown" is not a word you usually see in D3D docs or forums.

I prefer the ideas behind OpenGL, but it's reaaaaaaaaaaaaally lagging behind.
I've always thought Microsoft didn't kill OGL, but rather OGL committed suicide.

I don't know if the Longs Peak disappointment was caused by pressure from CAD developers and it's industry fellows. But if that's true, it beats the whole "Open Standard vs Single mega corporation" argument, doesn't it?

Share this comment

Link to comment
Where is directx 11 tesselation? Only on dx11 cards. How can you have support without the cards. Extensions come out as soon as the hardware is there. If cardmakers don't work with opengl then making a spec that requires hardware improvements is useless.

There's also not reason to limit yourself to the core of OpenGL, which is just tying your hands behind your back for no reason.

Effectively opengl is dead as far as moving forward goes, putting it in the hands of a committee assured that. That doesn't mean people should roll over for microsoft like puppies and let the accelerator marker continue into its downward spiral of incompatibility, though.

The future any sane developer would hope for is to move to more generalized accelerators which will lend themselves to actually working more than 23% of the time.

Share this comment

Link to comment
A nice balanced summary.

Historical note:

There WAS an issue with Vista's OpenGL support as Microsoft originally planned it - the OpenGL ICDs were not going to be integrated with the new compositing display driver model.

This meant that windowed OpenGL apps could either disable the Aero UI and use the ICD or keep the Aero UI and use a D3D wrapper limited to OpenGL 1.4. Full screen apps would always have used the ICD.

This would obviously have put windowed OpenGL apps at a disadvantage by forcing their users to disable the new UI or by forcing the apps to limit themselves to not using newer OpenGL features (with no access to them via extensions either).

Heavy lobbying of Microsoft by IHVs and ISVs pushed them into providing the hooks needed to integrate ICDs and the new driver model before Vista left beta.

A thread on opengl.org's forum, including contributions form IHV employees, is here for anyone interested.

So - there was going to be a problem with Vista's OpenGL support but it was all sorted out before it was released. I believe this is were the confusion came from.

Share this comment

Link to comment
Concise and well written.

I'd add that I do wish the ARB would get their act together and become involved in driving the development of the next generation of gfx APIs again. Not because I think they're super-awesome, but because I think that MS perform at their best when they're being driven to innovate.

The trouble is that OpenGL seems to have sat still, seemingly terrified to update it's API for fear of leaving existing implementations behind. Yet everyone accepts that each new generation of DirectX is going to break backwards code-compatibility so that it can give new features a chance.

Share this comment

Link to comment
One of the best article that I have seen in the past few months on this topic.

I have a question...I knew that OpenGL support in Radeon is buggy.But what about their support for DirectX.Is it good-to-go?

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now