Curious to who is sticking with OpenGL now...

[glfreak]

Me sticking with OpenGL since it works! Direct3D is still amateur, inconsistent behavior and lack of solid documentation. The SDK doc leaves many things ambiguous so that you never can tell if it's a bug or inconsistency in the way it should be used. Smart eh? Direct3D is great for single-windowed application with one viewport camera system. Try use a complicated multi-viewport CAD-like things and you are screwed up!

So yeah my graphics abstraction layer will still be implemented on top of OpenGL until we decide to support Intel graphics. I then will hire a D3D guru to write a D3D port.

OpenGL is what worked for me with less suffering over the period of 10 years of graphics programming.

[santyhamer]

I like OGL due to these reasons:

1. It's portable to other systems: Windows, MacOSX and linux, etc..
2. You can use DX11's tessellation in WinXP.
3. It supports relatively-new-things like tessellation, geometry shaders, MSAA, GPGPU via CL, etc...

Why not to use OGL then if you can?

[V-man]

I have seen minor change in the industry. New games either use their own D3D renderer or are really complex games and rent an engine that does D3D only.

Steam started paying attention to Mac OSX. They converted HL2 for OpenGL and a number of games are getting a Mac version.
That would be the minor change I mentioned. I say minor because I don't expect for Mac's to crush the competition.

GL ES is continuing to dominate. Nice.

As for GL 3.0, 3.1, 3.2, 3.3, 4.0, 4.1, I agree. Good stuff.

[ÐEMØN]

I am sticking with OGL because I see great potential with it over DX11. I'd love to see OGL annihilate DX11 in all areas. Judging by what I've seen in videos it's not far off from doing just that. What do you think needs to happen? Many people out there are making great suggestions that I think should all be implemented even if it does extend the next release date.

http://rastergrid.com/blog/2010/11/s...-2-and-beyond/ I read some of this last night.

[Chris Lux]

... What do you think needs to happen? ...

quality drivers... from all vendors.

[mhagain]

... What do you think needs to happen? ...

quality drivers... from all vendors.

Proper driver certification would go a long way. Conformance testing isn't enough here; a proper certification program is sorely needed.

[ÐEMØN]

Doubt that will happen any time soon.

[kRogue]

... What do you think needs to happen? ...

Developer "demand" for consumer GL. I love GL, I love that it is cross platform (atleast on paper). But what GL needs more is developers using GL. By developers I mean developers for consumer applications (read usually games). That is why Intel D3D drivers (though not that great) are better than it's GL drivers, the consumer demand for them to work well.

With Apple making a big success, we will see consumer demand of GL increase (simply because on the Apple platform that is the API to use). Too bad that Apple is not "keeping up" as it's GL still languishes in GL2.1.

Over in the embedded platform, GLES is mostly the way to go. (though this past Friday's announcement between Nokia and Microsoft potentially changes the land scape with respect to D3D vs GLES on those platforms, but there is Android, iOS, etc that are GL only for that jazz anyways).

And now we find we are in the chicken-egg area of adoption.... but GL is used in CAD so much, and I suspect that is why we see interest in GL for desktop from IHV's. Linux also has as a role, and naturally ID software. Outside of recent ports to Mac, and outside of ID software (or games using their tech) I have not seen a big consumer demand for GL.

I've love to see main stream software state "GL3.x required" as we now see for some games "D3D10 required".

Naturally, if MS-Window's severe dominance declines, then for desktop computers, GL will take a bigger role. Related to that are _tools_. The D3D platform does have excellent tools to debug and develop D3D applications, the GL analogue is not as strong. We have seen some things come (for example glDebugger is free!). Win the developer's hearts with tools and the consumers will come. But who makes the tools?

[elanthis]

Me sticking with OpenGL since it works! Direct3D is still amateur, inconsistent behavior and lack of solid documentation. The SDK doc leaves many things ambiguous so that you never can tell if it's a bug or inconsistency in the way it should be used.

I have to disagree, and feel that you have this entirely backwards.

Smart eh? Direct3D is great for single-windowed application with one viewport camera system. Try use a complicated multi-viewport CAD-like things and you are screwed up!

It sounds like you haven't used D3D recently. Remember that Microsoft (smartly!) breaks the API with each version to make wide ranges of improvements based both on feedback with the previous API and with changes in hardware.

Multi-window support in D3D 10 is lightyears ahead of anything you can do with OpenGL's magical hidden global context. Doing multiple-viewport rendering the _right way_ is just as easy in D3D as it ever could be in OGL, although OGL does making doing it the incredibly slow-and-wrong way much easier.

Which is possibly my biggest problem with OGL vs D3D. In D3D 10, all the old crap is just gone. It's not there waiting to confuse and screw over developers. It's a completely separate API from D3D 9, with different headers and everything. Microsoft fixed the parts of the old API that weren't as nice as they could be (compare to OGL where they overload functions like glVertexPointer so the argument that was a pointer is now an integer... it's just amazing that anybody ever thought that was even remotely acceptable API design), Microsoft removed the old API for features that hardware no longer really supports, and Microsoft tailored the API towards how the hardware is actually implemented. Meanwhile, OpenGL is still backwards compatible with the 1980's APIs that just flat out don't make any freaking sense at all to ever use on modern hardware (sure, they're gone in the Core profile, but that's just a meaningless distinction in reality, since you still include the same headers and link to the same libraries and no vendor actually lacks Compatibility profile support). That in turn just means that new programmers end up reading ancient documentation and tutorials (or worse, new documentation and tutorials written by similarly poorly-clued-in developers) and then write horrifically bad or poorly performing code.

Clean breaks in APIs actually have real, valid uses, and those uses include making the API easier to use and learn when the older versions' features become obsolete.

[Dark Photon]

Was it really worth reviving a 3 month old thread?

To each his own. Some us maintain and extend applications over many years, and appreciate not having waste our time with total rewrites to add in the latest GPU features just because Microsoft says so. We can focus on adding profitable features to our apps, adding to our company's bottom line, rather than burning it on mere "code churning".