Talk:Comparison of OpenGL and Direct3D/Archive 1

Archive 1

Archive 2

Please remove "reads like advertisement" if possible (2014)

I am finding the claim that this article reads like an advertisement distracting and puzzling, not helpful. I'm reading this article for the first time in 2014, not 2005. The latest revision seems well above the quality threshold for balance. It seems like it is time to congratulate the writer community and remove the "advertisement" characterization. This article is plenty informative enough. Please remove the confusing noise about "advertisement". Much of the Talk page (debates) dates way back to 2006. The 'advertisement' assertion at this time seems overzealous and more a problem than a solution; it is adding or introducing a distracting tone of conflict and is itself a problem. This seems like a polished, well-written, informative encyclopedia entry; there are worse, rougher articles that need work instead. — Preceding unsigned comment added by 2001:4898:80E8:ED31:0:0:0:2 (talk) 19:33, 25 September 2014 (UTC)

Intel Extreme Graphics

I'm not sure if Intel Extreme Graphics can be considered "low end" anymore, as they a) now support vertex- and pixelshader 2.0 (sure, the fillrate isn't all that, and the vertex processing is done on cpu, but still) and b) afterall 40% of all graphics processors out there are intel integrated chipsets. for developers, 40% is a BIG deal. supporting Intel Extreme Graphics well is usually a way bigger concern than supporting linux or any other non-mainstream operating-system. —The preceding unsigned comment was added by 195.18.161.22 (talk • contribs) 23:17, 21 August 2005 (UTC)

Reply: I am not sure when the above was written, but now I would say that intel is low end, since it can be overpowered by a $60 discrete card (which is certainly considered to be in the low end market segment). —The preceding unsigned comment was added by 71.198.190.10 (talk • contribs) 06:42, 6 December 2005 (UTC)

IEG chips are considered low-end because it doesn't provide the same performance that (some) cheap chips do. They also do not have dedicated memory, but instead use main RAM -- no VRAM for these chips -- which can hurt performance a lot. The number of features a chips has does not determine what segment it's in. If it performs significantly worse than another chip with similar features (possible more features) then it's lower end than the other chip. IEGs have significantly improved with the latest chips, but they are certainly still low-end. N.B.: Linux is a mainstream kernel.

Principle vs Principal

People! Please grab a dictionary and learn the difference between "principle" and "principal". "Principle" is a noun and it refers to concepts you live by ("do no harm"). "Principal" is an adjetive and it denotes status ("principal reason", "principal student"). "Principal" can also be used as a noun that denotes something with a principal status (a school's principal). —The preceding unsigned comment was added by 82.151.249.90 (talk • contribs) 13:04, 15 March 2006 (UTC)

Don't try and knit pick at things like that - discuss the topic. Also, it looks especially bad when you can't spell.

It's "nit pick" not "knit pick". 128.138.65.69 (talk) 18:00, 9 June 2011 (UTC)

Nitpick is one word 208.54.32.228 (talk) 19:41, 9 June 2011 (UTC)

lol 213.163.40.100 (talk) 10:00, 7 May 2013 (UTC)

Partial Rewrite

I've cleaned up this page somewhat, mostly by deleting obviously redundant and irrelevant information. It now reads coherently. I'm not enough of an expert to feel confident tinkering with the facts too much though. If there are as many factual errors in this page as the talk page indicates, somebody get on it and correct them!! --User:KaS_m

I've continued a general clean up. It's no good to be just adding sentences at the end of some fanboy's rant. We need to be attacking the rant as well as it's meaning. Wayne Hardman 04:35, 27 January 2006 (UTC)

DirectX stats

This paragraph was removed with the edit comments of : please don't compare directx to opengl. This article is direct3d vs opengl. If you want, you can bring stats on how many games use opengl vs direct3d renderer.

For the computer games market, some studies have shown that almost 80% of all games are still programmed solely in DirectX while only 5% are programmed solely in OpenGL. The remaining 15% are built for both APIs. This is expected to change as better OpenGL drivers are being released and OpenGL APIs are becoming increasingly popular among game developers.

I cant really see a game that used Direct3D and not DirectX or a game using DirectX and not Direct3D ( unless they are using a software render and DirectDraw, but that would just be silly). However is it original research ? --2mcm^Gespräch 20:33, 6 November 2005 (UTC)

DirectX is also used for input and sound, which makes it quite possible to use at the same time DirectX and OpenGL. Comparing OpenGL and DirectX is comparing apples and oranges; comparing OpenGL and Direct3D (or for instance SDL and DirectX) makes more sense. --cesarb 21:25, 6 November 2005 (UTC)

It's possible, but in practice it's rare to none. OpenGL in commercial games is only used for portability - in which case they have to drop DirectX anyway. // Gargaj 23:41, 6 November 2005 (UTC)

That isn't the only motivation. It's actually not uncommon for games to use Direct X but not use D3D preferring OpenGL. For examples see id Software's OpenGL based engines. Plenty of middleware is also ported using DirectX under whatever portability layer exists + OpenGL.

Article usefulness (and NPOV)

This article is full of useless, wrong, outdated statements which damages both OpenGL and Direct3D. It shall be rewritten from scratch by sure means.

Some examples?

• OpenGL is object oriented. The point is that many objects are just not exposed for compatibility reasons.
• Direct3D closer to the hardware and providing finer control because of missing devices? Who wrote this really does not know about the basics Direct3D internals.
• There are various Pixel Shader models, as we all know.
• Difference between gaming and professional applications? Pretty close to nothing now that everything is being driven by shaders.
• Hi-end cards not supporting Direct3D? I hardly believe it. My old 3Dlabs supported Direct3D5 fully, although at slow performance. It was many years ago. (<-- Agreed, I actually corrected this in the article).

I could possibly show how much of this article is wrong. This is to tell readers: don't trust this article! MaxDZ8 21:16, 7 November 2005 (UTC)

Is this in need of a {{not verified}} ? I'll find some other sources and compares those too. --2mcm^Gespräch 03:53, 8 November 2005 (UTC)

Now I know this exists, I propose {{Template:Cleanup-rewrite}}. The point here is that it's likely to proof almost every statement and its opposite without too many concerns. Many OpenGL users I've contacted are showing extensive zealotry while many Direct3D users didn't impress me for their technical skills. There are some issues to consider from the OpenGL side (such as the version to compare against) by sure means. I'm not really used to Direct3D but I believe some effort shall also be spent here. Considering the huge amount of work and attention this page will always need, maybe proposing a deletion could be something (I see this is possibly too drastic however). MaxDZ8 13:02, 9 November 2005 (UTC)

Alternate Source?

Would it be worth considering this article: http://www.gamedev.net/reference/articles/article1775.asp As a more trustworthy and reliable reference? It shows some bias towards OpenGL, but if we can borrow facts from it (or just ask the author to contribute), that might be useful.

It effectively looks good but I'm not sure it fixes the problem of this page requiring some work. MaxDZ8 20:00, 14 November 2005 (UTC)

Just fix it

There is a lot of accurate and reasonable stuff in this article, how about editing the stuff you don't agree with instead of throwing the baby out with the bathwater? The truth does not always lie half way between two positions.

Sigh just took a look at this a bit more closely, there really is some crap in here. Look people, if you don't understand the subject then don't frikin post, paraphrasing it says "D3D uses COM so every texture is an object unlike OpenGL which doesn't has a similar paradigm"???? Talk about getting your wires crossed. Please DO NOT post unless you know exactly what you're writing about, not what your friend's cousin's dad said. I may take a big stick to this article soon, it will probably involve a lot of deleting. Sometimes it's best not to post some opinions and this entire article is of limited use to anyone, even an objective discussion is of limited value and will always be disputed. Didn't this thing used to be more accurate? It seems a bit like death by a thousand tinkerers. The article should probably steer clear of conclusions and simply mention some of the history and surrounding API issues e.g. Microsoft and portability.

More nonsense in there about OpenGL being used for pro apps because they were originally written on OpenGL workstations. This is just WRONG, there is a whole history that started with Microsoft saying D3D was games only and it was (no stencil, execute buffers etc. etc. etc.), and trying to claim that OpenGL was for pro apps not games (it wasn't as Carmack demonstrated). The fan boys have been busy and apparently they just don't know what really went on. I have no confidence that fixing this article won't result in subsequent similar errosion of the facts.

You taking a big stick? I already did once in the past, it's going to happen again soon. This thing is in sore need of an entire re-write from the ground up to be an impartial discussion of the two (converging) APIs Wayne Hardman 04:22, 27 January 2006 (UTC)

I know very little about 3d stuff but I found this articler really helpful and interesting. Now I know why Direct3D is slower on my nVidia card. Please don't be a jackass and delete this article because you think you know more.

With all due respect, there are numerous potential reasons why D3D runs slower than OpenGL on your card, and the design of the respective base APIs is among the least likely. (This is not to say that the article should or should not be revised.) ERobson 17:44, 28 January 2006 (UTC)

Some Cleanup

I did some cleanup work on the areas I found to be NPOV (as of Jan 10, 2006). Post commentary on the cleanup below.

- Korval

As a 3D developer...

...I would agree that this article needs a lot of work.

Execute buffers did not become obsolete in DirectX 8. DrawIndexedPrimitive() was already available as far back as DirectX 5, and DirectX 6 had SetTextureStageState(). It was device setup, not state management, that DX8 improved.

Starting with DirectX 7, Direct3D gained a texture management mechanism similar to OpenGL's, called managed resources. However, some resources cannot be allocated this way, and dealing with the device getting hosed on Alt+Tab, and not crashing or having textures goofed up, is still a problem. OpenGL programmers are largely spared this annoyance.

I'm really surprised that no one has noted the difference in draw call speeds between the APIs. In the OpenGL case all calls go straight into the IHV's OpenGL user-space driver, whereas in Direct3D's case calls have to be translated through Microsoft's layer first. As a result, there is a significant difference in the rate at which meshes can be dispatched to the device. Direct3D is well-known for having abnormally high CPU overhead for its DrawIndexedPrimitive() function, which is a problem because every shader or texture change requires a new batch. Fixing this is a major priority for Microsoft in DX10. Thus, given a good implementation, OpenGL does have an inherent speed advantage in the current way it is integrated into Windows.

NVIDIA has a presentation from GDC2003 that shows OpenGL as around 2x faster than Direct3D at batch dispatch on page 14: http://developer.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf

None of the Intel parts have any hardware vertex shaders, so all transform and lighting must occur on the CPU. (Source: Check caps bits chart in latest DirectX SDK.) In addition, they have low fill rate due to unified memory. So, I would agree with the comment above that the Extreme Graphics parts still have to be treated as low-end.

The primary reason OpenGL drivers are complex is not because of state management, but because almost all features in the base API are mandated and thus have to be emulated in software by the driver if they are not accelerated in hardware. In practice, this requires a full software rasterizer.

The last few paragraphs in the User section are biased toward Direct3D in my opinion. The Direct3D API never matched hardware registers and drivers have to reinterpret the execute buffer that it writes. Direct3D drivers have been just as buggy as OpenGL drivers (remember 3D Winbench's quality tests?). The part about OpenGL having seldom-accelerated features is true, but there are features in Direct3D that have never been supported by any driver on the planet, even the Microsoft-provided reference rasterizer. You can try testing for D3DPTFILTERCAPS_MINFGAUSSIANQUAD for a StretchRect(), but you will never find a way to test it, and since there is no formal spec for Direct3D (unlike OpenGL), there is no documentation that tells you exactly how it would work either.

67.122.209.110 09:56, 1 February 2006 (UTC)

removed NPOV

I've removed the NPOV tag from the article. As a whole, the article isn't all that bad w/r/t presenting a fairly balanced point of view between the two APIs. If anyone feels that there's an NPOV problem, let's focus future efforts to resolve that on individual sections instead of labeling the entire article as being disputed. Warrens 23:24, 12 March 2006 (UTC)

Newer articles please?

I was about to revert Promit (talk · contribs)'s addition of a four year old (feb. 2002) article, when I checked the other two. One seems to be from 1997 or 98 (certainly before 2000). The other is hard to tell. It mentions D3D8, whenever that was. Can we have some newer articles? I'd like to see more comparisons now that OpenGL 2.0 has added shaders and streamlined the rendering pipeline. Imroy 08:18, 17 April 2006 (UTC)

Rename?

I think the name of this article needs to be fixed - this isnt a competition, its a comparison. Most computing comparison articles (also see its subcategories) are formatted in the style of Comparison of x and y. Does anyone agree that this article should be moved to Comparison of Direct3D and OpenGL? Remy B 11:36, 16 May 2006 (UTC)

Good idea! This "vs." stuff is a bit too combative for my liking anyhow. Warrens 14:31, 16 May 2006 (UTC)

Done. Remy B 04:03, 17 May 2006 (UTC)

Backward compatibility

A short discussion of backward compatibility would be nice. Many pc-games of the 90ies don't run on todays computers anymore because directx does not age gracefully. It would be nice if someone pointed out the advantage of opengl in that area.

This makes assumptions that would have to be proven. The problem with these games may have nothing to do with Directx.

For example take the problem someone had with LucasArts' The Curse of Monkey Island on yahoo answers where the problem was the program was likely was using some non Directx API that had likely changed in the 11 years since the game came out.

Frankenstein: Through the Eyes of the Monster is an example of bad programing as it had problems with Quicktime that Myst a far older game never did.

These two 90s games show that a game's problems may have nothing to do with Directx but with changes in the OS itself or a programmer who didn't know what they were doing.--BruceGrubb (talk) 07:27, 24 September 2009 (UTC)

Windows Vista

Cameron: I've updated the section on Microsoft's OpenGL implementation. It does in fact offer hardware acceleration in Vista in beyond. This is because their new OpenGL library converts down to DX. It's slower than vendor ICD's and has far fewer features. — Preceding unsigned comment added by 108.90.2.142 (talk) 00:40, 5 February 2012 (UTC)

grr... I added a whole bunch of information on this to the portability section without noticing there was already a section for it further down the page (also using Windows Aero where I ought to have been using Desktop Window Manager) :(

However, I don't think this information even needs to be on this page at all. It is not relevant to the comparison between Direct3D and OpenGL. It is discussion regarding how Microsoft were planning on implementing OpenGL support in Windows Vista; the fact that they will offer a slow and restricted OpenGL 1.4 emulation with Direct3D 10 when drawing to DWM managed windows tells you nothing about the pros and cons of the two APIs. The information ought to be on either the OpenGL page, the DWM page, or the Windows Vista page. As a matter of fact, it is already on the Windows Vista page, so I will delete it from this page, because it serves no purpose here. I will save some of it though, and add it to the Windows Vista page later to emphasize that for a period of time there was a real controversy surrounding Windows Vista and OpenGL. Moskvax 10:02, 5 July 2006 (UTC)

whoops, forgot to sign the last comment there. I'll just add now too that I plan on rewriting most of this page in the near future, using what's already on the page as a basis and expanding/deleting from it to try and get a better article. Moskvax 10:02, 5 July 2006 (UTC)

actually scratch all that, i'm too busy now to do it... Moskvax 18:11, 10 July 2006 (UTC)

Can anyone confirm that the mentioned OpenGL 1.4 to DirectX translation layer is actually present in Vista RTM? I never managed to see this in action and I believe that it was actually phased out before release because it was already clear that the IHVs would continue shipping and supporting full (DWM-compatible) ICDs, as they did on the Windows versions before. KeyJ (talk) 12:09, 21 November 2007 (UTC)

NPOV

This article is clearly in favor of OpenGL--I was a casual reader, and the bias is over the top. Very, very few sources cited for most claims, an anti-Microsoft feel all the way around. I wouldn't be useful in fixing it, as game programming isn't my thing, but thought I should point it out. Quite a bit in the way of weasel-wording, as well. TrevorRC 19:32, 10 August 2006 (UTC)

Could you be more specific? I've read over the entire article, and I really don't see what you're talking about. Here are examples from the article of things that refer to the advantages of one or the other:

Being a proprietary Microsoft product intended for use only on Microsoft-supported platforms, one natural limitation of Direct3D is its lack of portability. For some applications this is irrelevant: computer game developers, for example, may decide that as the non-Windows segment of the computer gaming market is as of 2006 much smaller than the Windows segment, porting their games to non-Windows platforms is not a priority, and hence lack of portability is not a concern.

Direct3D 10 allows portions of drivers to run in user-mode, thus allowing D3D10 applications to overcome this performance limitation. Outside of this, Direct3D and OpenGL applications have no significant performance differences.

The advantage of OpenGL's inclusive, extensible approach is limited in practice, however, by the market dominance Direct3D has achieved. In recent years, games have rarely implemented features until Direct3D has supported them, and graphics cards vendors have been reluctant to implement features that current or upcoming versions of Direct3D will not support.

Really, I can't see much of a bias either way. Could you offer quotes from the article and asses their bias? The only thing that seems to disparage Direct3D at all is the "Ease of use" section, which refers to specific problems that earlier versions had, and how they were fixed in later version (which to me supports DirectX as much as it detracts). - Rainwarrior 20:28, 10 August 2006 (UTC)

Sorry about the original posting of this at the top, thanks for the fix. I'm relatively new to Wikipedia, so still getting the hang of things... back on topic.

Portability

A paragraph-by-paragraph 'summary' if you would, Direct3D is only made for Microsoft-based use, anything else is severely limited. OpenGL, on the other hand, is used on 'everything'. Microsoft intentionally crippled OpenGL. Direct3D is only intended on Microsoft-based platforms, and is thus inherently limited, though most people solve this problem by ignoring non-Windows platforms. That's the way it came off to me--As it is, OpenGL may be vastly superior to D3D in terms of portability (and according to this section, it is.)

Ease Of Use

Starts out with In its earliest incarnation, Direct3D was known to be rather clumsy to use. No comment on OpenGL's origins. That paragraph (and the next one) are both devoted to talking about how terrible D3D was in it's eariliest forms (With one redeeming sentence Currently, Direct3D's API is a well-designed API.

Even so, there are functional differences in how the two APIs work. Direct3D expects the application to manage hardware resources; OpenGL makes the implementation do it. This makes it much easier for the user in terms of writing a valid application, but it leaves the user more susceptible to implementation bugs that the user may be unable to fix. "Direct3D expects _______, OpenGL makes sure it is so. This is easier..., though there is a minor drawback."

In that same paragraph At the same time, because OpenGL hides hardware details (including whether hardware is even being used), the user is unable to query the status of various hardware resources. So the user must trust that the implementation is using hardware resources "best". Yes, it does point out something that OpenGL doesn't do well; but it does not point out something that D3D does well that OpenGL does not. (As above.) No such example may exist (my knowledge on the subject is limited, so please forgive me), but I'm skeptical of that.

Performance

Paraphrasing (If you've noticed, I'm somewhat....liberal with my quotes. I try to add humor--forgive me if it's unwanted. "D3D is worse than OpenGL, Microsoft crippled it intentionally." It ends on a somewhat equal note saying Outside of this (this being all of the above D3D problems) there are no significant performance differences.

Structure speaks ENTIRELY of OpenGL. There are minor references to D3D, the ones that do exist are negative:

OpenGL is designed as a feature rich API regardless of hardware support. The specification often drives the implementation of hardware acceleration for these features. For example, when the GeForce 256 graphics card came out in 1999, games like Quake III Arena could already benefit from its acceleration of Transform & Lighting, because the API was designed to provide this feature. Meanwhile, Direct3D developers had to wait for the next version of Direct3D to be released and rewrite their games to use the new API before they could take advantage of hardware-based Transform and Lighting. Which simplifies to: "Programmers using D3D had to sit around and twiddle their thumbs until the newest version was released. OpenGL users, on the other hand, were set from the get-go."

The advantage of OpenGL's inclusive, extensible approach is limited in practice, however, by the market dominance Direct3D has achieved. OpenGL's advantage is hindered by D3D's market dominance. And finally....

In recent years, games have rarely implemented features until Direct3D has supported them, and graphics cards vendors have been reluctant to implement features that current or upcoming versions of Direct3D will not support. OpenGL has again been hindered by D3D's market share because vendors won't support a minor part of the market. (Same as above.)

Extension

(As far as I can tell) is fine.

Users

Looking again it seems to be ok, though it should probably be split into "Professional Users" and "Home and Game Users" or something to along those lines. (Professional Use & Gaming Use, perhaps? Though with Vista's desktop 3D, Gaming Use won't be correct in a year or so.)

Sorry if my formatting isn't quite Wiki-standard. I'm working on it =] TrevorRC 22:59, 10 August 2006 (UTC)

As far as I see it, every quote you have taken here is truth. And you don't seem to be disagreeing with them either, you just don't like the wording for some reason. I've written a point by point response. I've bolded the few cases where I agree there might be a problem.

1. 1. OpenGL -IS- vastly superior in terms of portability. Direct3D does not exist outside of Windows and the X-Box. This is a fact.
   2. Direct3D was indeed clumsy at first, that's why they fixed it. I think explaining this history is necessary to defend Direct3D, because if you google D3D vs OpenGL, you'll often come up with old arguments that are no longer valid (such as Carmack's old .plan thing), and this explanation on wiki makes it clear why those arguments existed, and why they are no longer valid arguments.
   3. I don't really see why any statement such as "OpenGL has an advantage in terms of X, but a disadvantage in terms of Y" should be considered POV unless you think it is untrue.
   4. You don't have to point out an advantage of one system to match every disadvantage. If the systems are unevenly matched in truth (and Direct3D and OpenGL are far from equivalent), the article MUST reflect this.
   5. Windows' implementation of OpenGL -was- inefficient. This is a fact. That's what CosmoGL proved. It was a result of their decision to focus on Direct3D. It doesn't say that they "intentionally crippled it", but it is true that the implementation just wasn't very good. Microsoft continues to neglect proper OpenGL support (e.g. Windows is still using OpenGL 1.1), which is a big problem that programmers have to work around with "extensions". Microsoft hasn't been interested in OpenGL in a long time, and why should they? They make a competing product.
   6. The Quake III example is another real example. OpenGL is designed to be extensible like that; it's easy for card manufacturers to provide extensions for OpenGL. For Direct3D it's tricker, so these things happen. Sometimes programmers just don't have access to the new hardware features because D3D hasn't been updated recently.
   7. Maybe the wording on this is a little weird. D3D has a big handle on the Windows market (which is a big market), and Microsoft has been making every effort to more strongly integrate D3D into their operating system. Again, it's a reasonable decision, business wise.
   8. I don't know if it's true that card vendors have held back features until Direct3D supports them, but I doubt it. This'll need a citation or something... but it doesn't make sense to me. The hardware has to come first. Microsoft isn't making graphics cards; they don't know what's next in the technology; the card makers do. Why would D3D lead the way?

The point of this article is not to favour one or the other, nor is it to claim that they are equal, or equally good. That is not "neutrality". Neither of those concerns is relevant: what the article is about is the differences between OpenGL and Direct3D. Each has advantages, and they are adequately outlined, I think. Each also has disadvantages, and we must discuss this as well. When you said it isn't neutral you are asserting that facts are being deliberately omitted (or falsified) in order to favour one side. If you are going to argue that the article isn't neutral, you must either provide the missing information, or point out false information. - Rainwarrior 06:22, 11 August 2006 (UTC)

I've removed the NPOV tag--I'll do a bit more research then come back, preferably with more than a gut feeling that something is biased. Thanks for the input. TrevorRC 16:37, 11 August 2006 (UTC)

Ummonk 22:42, 6 December 2006 (UTC) I, as a Mac developer also think this page is biased against Direct3D. I too, noticed that the Structure section only mentioned openGL's advantages.

Knowing a bit about OpenGL and it's history I cannot see how this article is biased (in the grander scale). There are a few areas that could be made clearer, but all in all I really cannot see any problems. I can only agree with Rainwarrior break-down of his point-by-point defense of the article. Instead of writing that vendors have not implemented certain features because D3D didn't support, it could be reworded into somethin in the order of 'some people speculate that some vendors have not implemented certain features of OpenGL because D3D doesn't support it' -- this is certainly true (we have at least one example of a person who speculates this), but may not be. User:Ummonk -- please provide some disadvantages of OpenGL and/or some for Direct3D to be included. If you don't know of any, then I will choose to disregard your critic of the article. I will (also) remove the NPOV tag. These things are very minor and easily fixed. FrederikHertzum 21:55, 12 July 2007 (UTC)

Words that are just vague enough to be true are to be avoided. If you want to say that someone has speculated something, make it a specific person and provide a citation. Actually, on the issue of whether hardware support waits for D3D, there are definitely counterexamples to the suggestion made in the article. For instance, if I recall correctly, ATI chose to skirt the DX9-S.M.3.0 vertex texture fetch requirements in a kind of underhanded way (article here), and instead implemented a render to vertex buffer capability, which for a while was only accessible as an OpenGL extension because it had not been implemented in Direct3D. This is a case where the hardware vendor (and not a minor one!) has deliberately subverted the D3D specs in order to encourage a technology they felt was superior. - Rainwarrior 04:52, 13 July 2007 (UTC)

Agreed on the vague words notion. These counterexamples should be incorporated into the article, if for no other purpose, to clarify that it happens the other way around (too?). Actually, i would like to strike the part of the article, since it hardly has any real value except for propaganda (regardless of how you put it). It's not relevant for OpenGL and it's not relevant for Direct3d -- and certainly not for a comparison of the two. Perhaps a rewrite is in order -- which actually compares the current state of the technologies, without concerning itself with current implementations, but only current APIs. Historical concerns should be left to another article (their main articles or a history article related to the two) -- it's simply not relevant to know how OpenGL evolved or how DirectX evolved, if you want to know about how things look today (but it may be interesting to know in case you want to know why OpenGL/Direct3d looks the way it does today.FrederikHertzum 13:08, 13 July 2007 (UTC)

I hadn't thought of that before, but I agree with you on the history issue. We should compare their current or recent states, and perhaps leave the history to its own section at the bottom. I think we should still have the history, but not scattered throughout the article. It distracts from getting to know what is actually going on today. - Rainwarrior 15:24, 13 July 2007 (UTC)

It also makes it very easy to see POV that's not there. Are you going to edit it?FrederikHertzum 18:43, 15 July 2007 (UTC)

I won't make that change just yet. It'd take a bit of effort and I'd want to wait until I have the time to do it right. I'll put it on my list of things to do, but in the mean time if you want to do it, go for it. - Rainwarrior 20:49, 15 July 2007 (UTC)

Time is of the essence. I won't be able to as I'm going away for a couple of weeks. After this I'm going to be home for about a week and then I'm leaving again -- both times to places with no internet. In a month I'd be able to and if you haven't done anything I'll certainly have a go at it.FrederikHertzum 20:08, 16 July 2007 (UTC)

What?!?! How can you possibly NOT think this is biased? You'd have to be the one agreeing with the bias to think that.... When a section begins with how poorly D3D was implemented and then says nothing about how OpenGL was first implemented, how is that not biased? Just focus on the bad of one and not mention whether good or bad about the other. I assume OpenGL just magically had absolutely no problems when it was first implemented? Does it also shit icecream?

Questions about update by Nicholas wilt

A recent addition to the article speaks heavily about "user" and "kernel" modes, which needs some clarification.

(Another issue though, is that DOOM and Duke Nukem are poorly placed examples. DOOM was not DirectX, Duke Nukem was a 2D platformer. The paragraph, however, does not make it clear whether the software rendering being spoken of has anything to do with either DirectX or OpenGL, though it implies that DirectX allowed them to have better performance.)

Also, we have:

OpenGL drivers are written in user mode, while DirectX drivers are written in kernel mode. As a result, OpenGL driver developers have the option of making hardware registers visible from user mode, which improves performance but compromises system security

And later:

In practice, OpenGL drivers still must make frequent user/kernel transitions; DirectX is designed to minimize the number of API calls and the number of kernel transitions

When must OpenGL make these user/kernel transitions? OpenGL doesn't have anything called "user" or "kernel" mode in its specifications, is this something to do with Windows implementations? What are these modes? Also, if it's written in user mode, and that is its advantage, why does it have to switch to kernel mode? (Can we add some context here at least about Windows architecture that explains what these terms mean?)

Also, how does this affect security? This statement is just dropped in there without any justification. It seems the opposite from any information I can manage to dig up on it: Code operating in kernel mode has fewer restrictions than user-mode code, but with the greater freedom comes a much larger risk of damaging the system. [1], when a kernel-mode driver fails, it can crash an entire system, whereas the failure of a user-mode driver causes only the current process to crash [2].

-- Rainwarrior 16:26, 23 August 2006 (UTC)

The distinction between user mode and kernel mode has nothing specifically to do with Windows. See CPU modes. --Imroy 16:45, 23 August 2006 (UTC)

The information at CPU modes was more or less what I expected; thank you for directing me there. I was unfamiliar with the term "kernel" and "user" modes. But, as far as I know, there is no mention of this kind of switching in the OpenGL documentation (and there shouldn't be), so these comments about it requring these switches are going to be implementation dependant. It's not going to do the same switches in different implementations. (OpenGL's inconsistency is indeed one of DirectX's advantages...)

My question is, where can I find out about where these switchings occur and how the effect performance? And how about these allegations about OpenGL's vs. DirectX's security? Do we have any articles or any kind of source we could reference to back these up?

Nicholas wilt's edit to me isn't very clear on the specifics, and they are issues I am unfamiliar with, so I'd like to be able to verify what he said and possibly improve it so that it is more clear. - Rainwarrior 22:27, 23 August 2006 (UTC)

I have both clarified and expunged Nicholas's edit. I found it to be less useful than it could have been, so I just rewrote the thing. Korval 22:52, 20 October 2006 (UTC)

FYI, Wilt is a well known industry expert, involved in the design of D3D, OpenGL drivers and GPU computation at Microsoft and nVidia. Articles are not improved when the contribution of an expert is removed by non experts because they don't understand it (e.g., CPU modes). 24.16.88.14 (talk) 04:37, 26 January 2009 (UTC)

Citations

The article is sorely in need of citations. For example, it makes many highly POV claims such as some of those mentioned above and a lot of others without citations. E.g. Direct3D in its earlier incarnations may very well have been clumsy and difficult to work with, but we really need citations to back this up. If we are going to make far reaching citations, we ideally need the view of more then one developer as well so just linking to a bunch of stuff Carmack said won't cut it either. In case anyone misunderstands I'm not saying this article violates NPOV. I am saying it needs citations, especially given the article it is. Nil Einne 12:21, 11 September 2006 (UTC)

Misleading/inaccurate?

Meanwhile, Direct3D developers had to wait for the next version of Direct3D to be released and rewrite their games to use the new API before they could take advantage of hardware-based Transform and Lighting.

I wonder whether this might be a bit misleading? I would assume developers had access to various beta versions of Direct3D long before it was released. Obviously, designing a product with a beta API which may change significantly and which may not be released by the time your game is ready is a risky move I would guess but U still suspect the above is inaccurate in that it appears to suggest developers had to wait for the new version of Direct3D to be released before they could even start programming for it... Nil Einne 12:30, 11 September 2006 (UTC)

Yes, the wording looks quite presumptuous. I'll amend that sentence. - Rainwarrior 15:32, 11 September 2006 (UTC)

NPOV again

I think that this article is nowhere near NPOV at all. Many sections clearly put OpenGL in favor by using comparisons that are inaccurate, and the wording clearly favors OpenGL as well. If there is a comparison article, all wording should be neutral, and the only thing that matters is the feature difference. For example:

OpenGL has always seen more use in the professional graphics market than DirectX (Microsoft even acknowledges OpenGL's advantage in this field[citation needed]), while DirectX is used mostly for computer games.

While it may be true that DirectX is primarily used in games, this sentence clearly states that OpenGL is more professional because of its use in "professional graphics market". I don't know whether or not this is true, but since when is the computer gaming market "unprofessional" (which the sentence implies)? I would say the whole article should be rewritten or completely thrown away. 129.187.41.9 17:26, 16 November 2006 (UTC) (yes, I don't like registering, enjoy my IP)

I agree that "professional" is probably a poor choice of word there. The rest of this is accurate though; outside of gaming, DirectX has far less use. In academic research, OpenGL is preferred for a number of reasons (open, portable, extendable), and if you read research papers they will bear this out. Pointing this fact out is not POV. Other than academic there are the professional graphics companies outside of graphics (i.e. animation), and again, OpenGL is preferred. You can read about Pixar, or DreamWorks, or even just look at their job postings, and you'll find that this is the case.

"OpenGL, introduced by SGI in 1992, is the most widely-used and supported interface for realistic 2-D and 3-D high-resolution graphics. It is an open, vendor-neutral graphics standard that works on a wide variety of platforms, including Linux. DirectX is a group of technologies for running and displaying multimedia applications on Microsoft Windows and Xbox." [3]

- Rainwarrior 19:30, 16 November 2006 (UTC)

Actually, looking it over, professional seems appropriate, but there is room for misunderstanding. I instead added a description of what professional is taken to mean here. When playing a game, you aren't using the graphics produced by the game for any commercial purpose; you are using them in your own home for your own purposes. If you are an animator, on the other hand, you are making graphics (the movie) professionally. - Rainwarrior 19:51, 16 November 2006 (UTC)

Still, the article somehow implies that computer gaming is not professional work (I'm talking about the development of games, and not playing them), which is in fact POV. Also, the rest of the article is not much better in this area. I'm not sure how many advantages OGL has over D3D or the other way around, but even if those are big, it doesn't need that "OGL 0wns D3D" feel in the text ;) 84.56.24.192 20:52, 16 November 2006 (UTC)

Well, outside of gaming, D3D vs OGL isn't much of a contest, and the article needs to make that distinction (the media arts have always been a bit Mac biased anyway). Inside of gaming, they seem to pretty much equivalent in terms of capability. It tends to come down to platform. If you want to make a game for XBox, you use D3D. If you're making one for Windows you should probably lean toward D3D because of the direction Windows Vista is going with OpenGL (non) support. If you want to make a game for Mac, PS3, or Wii, there is no D3D and you just use a form of OpenGL. The real problem is when you want to make a game on a variety of platforms: you have to have the time and resources to rebuild your engine in both systems, and in a lot of cases the resources aren't there. - Rainwarrior 21:54, 16 November 2006 (UTC)

 

There should be a clear distinction between "gaming" and "DCC" (Digital Content Creation).

Actually, D3D is being used on a few DCC tools (Autodesk Architectural Desktop comes to mind) so the bottom line is that they're converging to the same features and goals. Actually, the only thing you can do in GL that you cannot do in D3D is to compile shaders at runtime - a thing that you can solve by installing D3DX.

It should be noted that the GL Vista support will come in different flavours depending on how much your vendor likes GL. The two best options are rumored to be "full support with less performance" and "full performance without compositing". The GL-Vista issues have been solved in a more than decent manner in nearly all cases so please just let the thing die.

83.190.158.197 11:09, 17 November 2006 (UTC)

Use of professional - Professional, as used in the article, should refer to the end-user context for applications utilizing the library, not for the status of developers who use the libraries in their applications. Graphics artist, drafter (CAD) and (building) architect are professions. Video game programming/development is a profession. Ignoring the niche "sporting" aspect, and game testing, video game playing is not a profession. If there are any discrepencies or ambiguities, they should be fixed.

Where is the citation that OpenGL is "About equal" to DirectX in games? I highly doubt that. If its "about equal" why aren't there any equal amount of games put out in OpenGL? —Preceding unsigned comment added by 137.28.228.112 (talk) 05:08, 27 April 2008 (UTC)

Vendor lock-in and extensions

An anonymous editor added these two paragraphs to the extensions section:

Having a third party develop the specification (like with DirectX) instead of the vendors of the hardware itself (like with OpenGL) helps to prevent a Vendor_lock-in and promotes a wide variety of available 3D-acceleration hardware. (see Glide)

Moreover the OpenGL vendor-specific features lead to bad backward-compatibility, because some time after the feature becomes standardized by the OpenGL Architecture Review Board support is dropped for the (now obsolete) interface. This also leads to the fact that some old OpenGL applications do not run well or at all on new hardware, because the (back then) used vendor-specific features are no longer supported or have been from a different hardware-manufacturer in the first place.

1. The idea that an MS-only API prevents vendor lock-in is simply laughable. Direct3D has always been about vendor lock-in, for Microsoft. As to whether it avoids graphics card vendor lock-in is questionable and the anon did no explaining.
2. While the situation with extensions proposed by the text is certainly possible, I don't believe that is what happens in real life. Since it's relatively easy to publish an extension, the extra effort required to keep the old vendor-specific extension is minimal. For example, here on my Geforce 6200 card using the nVidia drivers, I see many extension names duplicated between nVidia and the ARB e.g:
   • GL_NV_fragment_program and GL_ARB_fragment_program
   • GL_NV_vertex_program and GL_ARB_vertex_program

Furthermore, I see extensions originally from other vendors, like GL_ATI_texture_float, GL_ATI_texture_mirror_once, GL_S3_s3tc, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_KTX_buffer_region, etc.

So the idea that extensions create vendor lock-in, or huge backwards-compatibility problems is simply not borne out by the evidence I'm seeing. Admittedly though, it does depend heavily on the OpenGL driver and vendor. --Imroy 19:14, 15 February 2007 (UTC)

Comparisons in an encyclopedia

Whatever happened to encyclopedias being strictly a source of facts? There should be no comparison article on anything, as any comparison is inherently, even when presented perfectly neutrally, loaded with opinion and bias, because if strictly facts were used, there'd be no comparison. This article should be deleted. Pfhoenix 19:39, 24 May 2007 (UTC)

I agree, comparison articles are stupid and just end up as a big disagreement. --137.205.76.74 23:20, 25 June 2007 (UTC)

I think comparison articles can be hugely helpful.. half the time when someone looks at the Direct3D or OpenGL articles and realizes their competitive nature, they're going to be wondering, what's the difference? Getting those differences can be much, much easier when you have an article about them. All it needs is some attention from experienced people. Which can be hard to get, I know.. LieAfterLie (talk) 23:32, 25 October 2010 (UTC)

Proposal for rewrite

Ok, I lied. I did have to time to write a bit. Here's what i have come up with so far. This is the style of information I would be interested in having in this comparison. Please comment and correct/add/remove as needed.

Overall comparison

OpenGL and Direct3d provide rougly the same speeds -- if it runs on the same hardware and both APIs are supported equally well, there is no reason to expect that two rendering engines which are implemented equally well will not run at the same speed. It is a common misunderstanding that one of these are slower than the other, however, since drivers and graphics hardware is as important to both APIs there is no reason to believe that they won't run at roughly the same speed.

OpenGL and Direct3d provide roughly the same features. Direct3d has a few advanced features which have still not been included in OpenGL -- but this is changing fast. By the end of the summer 2007 never specifications for OpenGL will be released which include these features.

Interestin read from one of developers : http://chrishecker.com/OpenGL —Preceding unsigned comment added by 84.16.123.194 (talk) 08:39, 10 May 2009 (UTC)

OpenGL

Advantages

OpenGL is implemented on almost all operating systems today. This includes all desktop version of Window, all versions of Linux (through Mesa), Mac OS X, as well as most others. This is the principle advantage of OpenGL.

Open Graphic Library.

OpenGL was designed with the future in mind, that is it was designed as a rendering API which did 3d rendering -- either in software or using hardware acceleration. Some of features of OpenGL may not be implemented in hardware accelerating drivers but then a software fallback can be provided so that the full system can still work. This means that OpenGL can innovate in ways that wasn't thought of by hardware designers and allow programmers to take advantage of functionality of OpenGL that's not implemented in hardware yet.

OpenGL is extensible. This means that anyone is able to implement a feature which isn't part of the core API and include it as an extension. These extensions are often implemented by many providers and it is not uncommon to find one providers extension in the drivers of another provider. If enough providers implement an extension it could end up as an official extension and could even be promoted to the core.

Also OGL has group of experts / firms behind it. (-) It takes time until they agree on something, but (+) then it becomes "standard" and is "well though trough"(?).

Diadvantages

OpenGL doesn't provide the means to get a rendering target -- this is part of the design. It does allow OpenGL to work in all types of graphical environments but it also hinders it's portability, since special code has to be written for each graphics system. This means that a program that uses OpenGL is not just a compile away from running on any other operating system. It also means that a developer usually has to know two APIs to get a rendering target to draw in, for each target platform. These two APIs are the normal API for aquireing the normal rendering target, and a special OpenGL API which transforms the normal rendering target into one that's possible to render into using OpenGL.

Direct3d

Advantages

The philosophy of Direct3d is that it should expose the capabilities of the current state of the art hardware. This means that if a program is run on a platform that has compatible hardware with current drivers the software will know what is hardware accelerated -- this allows for some optimization which could turn into higher performance.

When Direct3d is available it is also guaranteed that the a host of other APIs are avialable -- the entire DirectX family is present when any one is. More over, if the OS is Windows then all of these APIs. The DirectX APIs encompass things such as input, networking, sound and video. Mostly anything a developer could need when developing a graphics intense application is available in this family of APIs -- games especially.

Disvantages

DirectX is only available on platforms running an operating system developed and released by Microsoft -- this includs all desktop version of Windows. This means that a program that uses DirectX has to have all of it's rendering code changed if it has to run on any operating system that's not Windows. Considering that DirectX is mostly used for everything other than the graphics it also means that everything else has to be rewritten.

Direct3d does not have an extension system. This means that if a provider wants to add something to the API he will have to persuade Microsoft to include it. This means that only Microsoft will know what will be comming next -- it also means that you always know what you've got.

FrederikHertzum 20:06, 16 July 2007 (UTC)

In Microsoft's Lisence Agreement for DirectX they state you may not install DirectX on any computer OS that is NOT developed by Micrsoft. --71.170.1.101 00:21, 26 August 2007 (UTC)

Get rid of historical comparisons

There are still a lot of historical stuff in the article. I say we get rid of it, and only compare DX3D with OGL as it exists today.

Current facts are relevant. Last years facts are not. —Preceding unsigned comment added by 83.93.59.108 (talk) 20:35, August 30, 2007 (UTC)

But is that the case? Are we providing a commercial comparison for the purposes of choosing which API to use, or are we providing a record of the continuing competition between two major competitors? I think the latter is more reflective of the purpose of Wikipedia, to be honest, whether or not it is used for the former - 203.214.142.144 06:33, 30 September 2007 (UTC)

I think at least three of the links at the bottom can go away.

GameDev.net: Direct3D vs. OpenGL (last updated 2002) Paul Hsieh: Direct3D vs. OpenGL (last updated 1997!) XMission.com: Direct3D vs. OpenGL (last updated when 8.0 was released)

None of the information in these links are of any use, as they all compare obsolete versions of the various apis. Jmathies 17:03, 30 October 2007 (UTC)

Error in the Gaming Section

The gaming section is messed up. I have never seen a game that lets the user choose between DirectX and OpenGL. There is no development company that would go to such extents and lengths for a poor, if any, net gain. The example given is not even, fun as it is, a video game. Dylan 23:01, 31 October 2007 (UTC)

Most (if not all) Unreal-Tech based games allowed this. Some Quake2-tech based games also did (notably the first half-life). The net gain was massive at the time, with some cards having bad D3D drivers and some others not even with a GL one.
MaxDZ8 talk 07:27, 2 November 2007 (UTC)

Blizzard's World of Warcraft is coded with both DirectX and OpenGL implementations. Very specifically the Windows version can be switched between the two. It defaults to using Direct3D, but with the addition of something like "-OpenGL" in the shortcut location, it will switch to rendering in OpenGL. BOMBkangaroo (talk) 20:20, 8 December 2007 (UTC)

OpenGL not really used in console games

This statement is a bit misleading: "OpenGL has implementations available across many platforms including Microsoft Windows, UNIX-based systems such as Linux and Mac OS X, and the PlayStation 3 game console. Variants of OpenGL run on the Nintendo GameCube and Wii game consoles and the Nintendo DS[1] and PlayStation Portable handheld systems"

This gives the impression that PlayStation 3 games are written on OpenGL. In fact game engines written for PS3 prefer to use Sony's proprietary API for performance reasons. (Sony provide 2 APIs for PlayStation 3, one based on OpenGL ES 2.0 and a lower level proprietary one.) Similarly PSP and NDS engines don't use the OpenGL-esque API, perferring to access the GPU directly. —Preceding unsigned comment added by 81.172.90.47 (talk) 12:23, 9 March 2008 (UTC)

It's worth noting as well that the OpenGL implementations available on Wii, Gamecube, PSP, and DS are all written by the homebrew community and are not widely used in professional circles. OpenGL is not the "default API" on these systems, nor is its usage on these platforms common or widespread. In all cases it is a wrapper on top of another library. Also it is widely claimed that the GX library used on Wii and Gamecube is "inspired by" OpenGL, but having used this as a professional I find that their similarities are coincidental. GX is not API compatible with OpenGL nor does it use any of the same conventions, but it shares many high-level concepts with both OpenGL and Direct3D.

With this in mind, the Prince MacLean quote should be removed, since the claims he makes in the quote are misinformed and misleading. 64.111.160.21 (talk) 20:09, 8 January 2010 (UTC)

Some Factual Information

I propose along with rewriting this article, include maybe a table on factual information so people can compare what abilities each has instead of arguing over which is better. --//Blake D. Hawkins (talk) 01:03, 10 April 2008 (UTC)

Chris Heckler

Chris Heckler's "Open Letter to Microsoft" is cited twice (see refrences section). The two paragraphs (which are already, conveniently next to one another) need to be combined, to avoid this duplicate refrence.

Removed the nonsense about the desktop gaming decline

How could you overlook such a console-fan bullshit? —Preceding unsigned comment added by 92.255.151.4 (talk) 11:06, 14 March 2009 (UTC)

Nonsense? Look at any game sales chart in the recent couple years, it's quite clear that what you are saying here is the nonsense.123.117.20.216 (talk) 13:22, 11 October 2009 (UTC)

Full of FOSS FUD

I'm not gonna edit this article, but I'd still like to note that this whole consensus that OpenGL is the easier API, to which Direct3D is trying to catch up to, is nothing more than a dogma that's kept alive by the foss crowd.

Any professional game developer will acknowledge that Direct3D is by far the better solution of the two, taking the needs of a typical game render engine into account. OpenGL may be easier if you only want to do some scientific visualization, where you just want to draw a set of triangles/lines in the easiest possible way, but for games, where the pipeline is often much more complex, OpenGL's strict state machine model becomes nightmare to work with, while Direct3D's more object oriented approach keeps things much more straightforward.

Given this wasn't signed and has no reference to back up any of it I would say this is the FUD.

"the features offered by OpenGL 3 are pretty much the same as what Direct3D 10 offers, except for Geometry Shaders and Geometry Instancing, which have been added to the API as an extension." (Abi-Chahla, Fedy (2008) "OpenGL 3 & DirectX 11: The War Is Over" Tom's Hardware Guide 09/16/2008) The same article states "Further—and this is no secret for anybody—the PC as a gaming platform has lost ground in recent years with the emergence of the new consoles, to which several major developers from the PC world have now switched." It also points out that two of the main console use DirectX 9 GPUs effectively locking developers two steps behind DirectX 11 though given game development time there was hope the new DirectX will go somewhere as OpenGL 3 was seen as largely a rehash of DirectX 10.

"OpenGL is used by Linux and, more recently, by all of the major game consoles, including Sony's PSP and PS3 and Nintendo's Wii. The console exception is of course Microsoft's Xbox, which was named after the DirectX graphics libraries it was designed promote in an effort to stop a broad migration to OpenGL in gaming and a subsequent erosion of Microsoft's software monopoly." (McLean, Prince (2008) "OpenCL and OpenGL take on DirectX" Apple Insider December 16, 2008)

OpenGL will run on Linux, Mac, Windows, Playstation 2, Playstation 3, Playstation Portable, Nintendo Wii, Gamecube, and Nintendo DS. By contrast DirectX runs on Windows, Xbox, Xbox 360, PS3 (maybe the information conflicts on this), and that is about it. Even at its height you are talking about only 20% with the remaining 80% of the console market being OpenGL and the handhelds is OpenGL all the freaking way. Especially as the Xbox 360 has a staggering 54.2% failure rate! (Miller, Ross (2009) "Microsoft responds to Xbox 360 54.2 percent failure rate report, doesn't dispute the data" Engadget Aug 24th 2009)

No "professional game developer" who looks at the marketshare figures would think DirectX with its 20% of console 0% handheld would be a "better solution". No rational person who looks at the console+PC marketshare numbers could say that. Then you have OpenCL Apple's extension of OpenGL in the mix.--BruceGrubb (talk) 20:10, 22 September 2009 (UTC)

As someone who develops games, I have to agree with the OP (unsigned). OpenGL is, frankly, a nightmare to use on the PC. On most platforms you don't have a choice - you use the native library. The whole OpenGL vs. DirectX debate is only relevant on Windows since that's the only place where both are available. There's a reason for the complete and utter dominance of DirectX in PC gaming (Windows). I've found many PC game developers share this opinion. But it's not worth much since, of course, the plural of anecdote is not data. Take this information at face value.

However, the article you linked to ("OpenGL 3 & DirectX 11: The War Is Over") even says "We were expecting a lot from OpenGL 3, and as you can tell by reading this article, we’re disappointed—both in the API itself (with the disappearance of promised features) and in the way it’s been handled (a year-long delay and a lack of clear communication on the part of the Khronos group). With this version, OpenGL barely keeps up with Direct3D 10, and at a time when Microsoft has chosen to publicize the first details of version 11 of its own API."

I mean, heck, even John Carmack, one of the biggest supporters of OpenGL in the past, now prefers DirectX. This article is so unabashedly biased that I wouldn't even know where to start if I wanted to try and fix some of the more glaring issues. For goodness sake, entire "Gaming" section basically consists of information about OpenGL's dominance in the 90's, and a single quote from an opinion article from AppleInsider of all places!Sc4Freak (talk) 05:49, 30 October 2009 (UTC)

Desktop gaming decline Part 2

I also noticed the last sentence of this article made a ridiculous claim without any facts to back it up. Juding by the the comment two posts up it seems a console fanboy keeps adding this shit in.

Well there is a reference to this so called "shit" has basis; unless you have a source that contradicts this stop wasting our time with unsupported ramblings that you don't even bother signing.--BruceGrubb (talk) 23:20, 6 October 2009 (UTC)

This illustrates why Wikipedia, as a concept, is often a pile of crap. The last sentence in the article reads:

"Further—and this is no secret for anybody—the PC as a gaming platform has lost ground in recent years with the emergence of the new consoles, to which several major developers from the PC world have now switched."

This is simply the unsupported opinion of a writer on Tom's Hardware--I'm not saying it's not true, but it's not supported in that article by any references to data. In the rules of Wikipedia, having an unsupported opinion on another site counts as a "reference" and means the unsupported opinion can be used here. If the same author directly put his unsupported opinion into the Wikipedia page, it would be rejected as a non-neutral point of view. According to Mr. Grubb, there is no basis for removing the reference to the unsupported opinion until we find another website with a countervailing unsupported opinion. I believe that Mr. Grubb accurately describes the rules of Wikipedia, and that is why Wikipedia is essentially useless on matters of opinion.

But here's the real problem with that sentence. It's clearly being used to support OpenGL over DirectX, but if one actually reads the entire article from which the quotation is taken, you'll see that the author's general opinion is that version 11 of DirectX will surpass the latest version of OpenGL. The quotation used is nothing more than part of a description of the evolution of DirectX.

Furthermore, although the quote includes a citation, it does not mention the original source in the article body, which leads the reader to believe it was spoken by the same source as the previous rotation. —Preceding unsigned comment added by 72.242.210.10 (talk) 20:48, 15 December 2009 (UTC) Wait, adding onto my own post here. Having taken the trouble to read through the rest of this talk page, it's clear that Mr. Grubb is simply a fanboy with an axe to grind. That explains everything. I'll move along now. —Preceding unsigned comment added by 72.242.210.10 (talk) 20:53, 15 December 2009 (UTC)

The "structure" section contains baseless claims

"The API as a whole contains about 250 calls, but only a subset of perhaps 100 are useful for game development"

This can be trivially proven false by checking the OpenGL function registry: http://www.opengl.org/registry/. A quick count reveals that the OpenGL API (as of 2.1) contains ~600 core functions and ~900 extension functions. OpenGL 3.2 bumps those numbers to ~850 core and ~1050 extension functions for a grand total of 1900! Granted a large number of those functions are deprecated in 3.x, but drivers still export them for backwards compatibility - this is a far cry from the 250 functions claimed in the article.

That said, the above constitutes original research and I won't edit the article without some reputable neutral source. Would an OpenGL caps viewer, such as glview, count as such? —Preceding unsigned comment added by 77.49.249.166 (talk) 22:59, 22 January 2010 (UTC)

This section also links to "stencil," which has no information anywhere on the page about how stencils are used in graphics programming. It should either be removed, changed, or someone needs to add this information to the stencil article (I would, but I don't know of any sources that could be used)- Chakradragon (talk) 16:13, 13 October 2010 (UTC)

I redirected stencil to something more appropriate. Not sure though if that's the type of stencil that was originally meant... --DanielPharos (talk) 18:00, 13 October 2010 (UTC)

what about the light count?

I believe the fact that, at least until recently, OpenGL only allowed for a maximum of 8 simultaneous hardware accelerated lights while DX didn't had such limit, deserves even a whole section in the comparison article. --TiagoTiago (talk) 07:20, 6 February 2010 (UTC)

I think it does not, as this is old, old, old fixed function specific to let rot in its grave. But let's just read glGetLight man, or glLight:

“ The number of lights depends on the implementation, but at least eight lights are supported. They are identified by symbolic names of the form GL_LIGHT i, where i ranges from 0 to the value of GL_MAX_LIGHTS - 1.

...
It is always the case that GL_LIGHTi equals GL_LIGHT0 + i.

”

and then on glGetIntegerv, wrt GL_MAX_LIGHTS

“ params returns one value, the maximum number of lights. The value must be at least 8. See glLight. ”

As such, this is inaccurate. A more accurate statement would be that ... until recently, most GL implementations supported no more than 8 lights ... but I'd just let this out. I would be really surprised if some GL implementation really supported lights nowadays instead of just emulating them thuru shaders.

Let's also have a look at the D3D9 docs, more specifically to IDirect3DDevice9::SetLight:

“ Applications can set a number of lights, with only a subset of the assigned lights enabled at a time. Check the MaxActiveLights member of the D3DCAPS9 structure when you retrieve device capabilities to determine the maximum number of active lights supported by that device. If you no longer need a light, you can disable it or overwrite it with a new set of light properties. ”

Clearly, D3D9 is using lights using a different usage model.

Checking the devcaps, we can see this cap varies, with intel 945 exposing 0 (zero), radeon 9800 and beyond exposing 8.

We could then digrees on what a GL light is, as opposed to what a D3D9 light is. D3D9 has more mangling, as a result of its design in other stages... no, I don't see a much of a difference.
MaxDZ8 talk 18:20, 8 February 2010 (UTC)

Technology has indeed moved on in many instances. And i was somwhat misinformed back then; if i'm remembering correctly now, later i learned the issue was not the specification, but rather how people misinterpreted the specification hardcoding the maximum light count for OpenGL at 8 thinking the specification demanded that as upper limit or not expecting new cards to support more. Whether the issue was on drivers or software i'm not quite sure; but with several different programs, including a techdemo by NVIDIA itself, running in OpenGL mode resulted in a maximum of 8 simultaneous lights while running in Direct3D mode displayed a hugely bigger number of lights). --TiagoTiago (talk) 10:54, 18 May 2012 (UTC)

Emulation

After reading the last section about platform gaming, i felt the emulation community had been ignored.

A number of emulators for gaming systems have been coded to render games written in native APIs to OpenGL, and a few for Windows have been written to render native APIs to Direct3D (although even on windows there are more using OpenGL).126.251.69.241 (talk) 20:59, 11 February 2010 (UTC)

True, but even more use a software rasterizer, instead of an OGL/D3D layer. And some support both, via plugins. Generally, emulators released on multiple OS's tend to lean OpenGL, for portability reasons. --Gamerk2 (talk) 15:54, 26 May 2010 (UTC)

all consoles

all consoles except the xbox1/xbox360 now fully support OpenGL ES nativly (psp/ps3/wii), it's on the box/manual of both the wii and PS3 (OpenGL ES/COLLADA) Markthemac (talk) 00:56, 30 March 2010 (UTC)