Will DirectX replace OpenGL in game development?

[Ostsol]

That's just plain wrong.
WGL_ARB_render_texture is available since years.
From the extension registry : http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_render_texture.txt

Sure the capability has been around for a while, but its implementation was very poor. The following text from the EXT_framebuffer_object spec describes why previous extensions sucked:

Previous extensions that enabled rendering to a texture have been much more complicated. One example is the combination of ARB_pbuffer and ARB_render_texture, both of which are window-system extensions. This combination requires calling MakeCurrent, an operation that may be expensive, to switch between the window and the pbuffer drawables. An application must create one pbuffer per renderable texture in order to portably use ARB_render_texture. An application must maintain at least one GL context per texture format, because each context can only operate on a single pixelformat or FBConfig. All of these characteristics make ARB_render_texture both inefficient and cumbersome to use.

 

[Sigma]

I think some people are making some confusion regarding OpenGL versions and required extensions. If I would to use OpenGL2.0 right now I wouldn't need to use a single extension (except EXT_frame_buffer_object) to make a top level game. A version means only that some group of extensions are available. For example, I can either check for OpenGL2.0 or I can check extensions A+B+C+... at the extension string: same thing.

And that is exacly the same as D3D's cap bits. A game programed with DX9.0 doesn't mean that it uses Pixel shader or in fact that they are supported. You have to check it in the cap bits, like checking the extension string for ARB_fragment_program.

And in GL there isn't the PS1.0,1.1,1.4,2.0,2.0a,3.0 mess...

P.S.: I am glad they maintained GL2.0 backward compatible, because I do want to use glBegin/glEnd. They did the right thing, using "another" OpenGL (OpenGLES) to clean up unused stuff.

 

[KimB]

Using the extensions is a fairly common practice now, but that kills the cleanliness that GL was originally known for, and causes you to have to write the same thing several different ways

Er, OpenGL has been converging again quite nicely over the past couple of years. I challenge you to name one current extension through which it is currently necessary to program separately for ATI and NV hardware (well, two, I guess: one for ATI, one for NV).

 

[KimB]

...
nevermind

 

[PARANOiA]

Er, OpenGL has been converging again quite nicely over the past couple of years. I challenge you to name one current extension through which it is currently necessary to program separately for ATI and NV hardware (well, two, I guess: one for ATI, one for NV).

Didn't Doom3 have a handful of paths depending on hardware?

I guess you could say it's not necessary. But performance was shit, and no one would buy your game if you didn't

 

[no_way]

AFAIR it's OpenGL 1.1, it was to be updated to 1.2 with win2k but it never happened.
There are a few small libs that let you use the extensions painlessly, like GLEW...

http://www.opengl.org/documentation/implementations.html

"OpenGL v1.1 ships as part of Win32"

 

[KimB]

Didn't Doom3 have a handful of paths depending on hardware?

I guess you could say it's not necessary. But performance was shit, and no one would buy your game if you didn't

It did, in development. Now there are no vendor-specific paths (as far as I know....there aren't for shaders, at the very least).

 

[AndrewM]

It did, in development. Now there are no vendor-specific paths (as far as I know....there aren't for shaders, at the very least).

There most certainly is, for older hardware. GF3/4, 8500 etc. ARB paths (dot3 etc) for GF1/2 and 7500.

What does it matter anyway?

 

[KimB]

Hence the word "current."

We're at a point now where games that have started production within the past year or so shouldn't even care about supporting DX8-level hardware (provided said games seek to push tech).

And since the argument I placed won't even apply until around the time that Vista comes out, well, I'd say DX8 and previous-level hardware doesn't have any bearing here.

 

[Ladis]

One of the things so-called "pure" GL 2.0 was *supposed* to bring was to clear out all the extensions and roll the important ones directly in as API features as well as get rid of the fixed function pipe.

It happened in OpenGL ES 2.0 (i googled this article about it):

OpenGL ES 2.0, an improved derivative of OpenGL for use in cellphones, embedded systems, including Sony's Playstation 3... promises to be leaner and more versatile than its predecessors, by reducing or eliminating some of the older, so-called "fixed function" libraries that characterized the original OpenGL. As Trevett told Tom's Hardware Guide, this will also reduce the API's footprint while concentrating on more modern, adaptable techniques such as programmable vertex shading libraries.

 

[Broken Hope]

Seems Microsoft wants to kill off OpenGL

Link

 

[KimB]

If you read down near the bottom, it's not as bad as the first poster makes it out to be.

Basically, if you run in full OpenGL, the desktop 3D acceleration is turned off. You can use OpenGL along with the desktop 3D stuff if you use the Microsoft OpenGL wrapper.

What this may mean is that apps that run in windowed mode will run very slowly and without extensions. I can see a whole host of compatibility problems creeping up as well.

 

[Dave Baumann]

Presently it limited to OpenGL 1.4 as they are wrapping it through WGF1.0 / DX9, not DX10.

http://www.beyond3d.com/forum/showthread.php?t=22406

 

[Hyp-X]

http://www.beyond3d.com/forum/showthread.php?t=22406

That link doesn't work

 

[Rodéric]

There's a discussion about that here:
http://www.beyond3d.com/forum/showthread.php?t=22400

 

[aaaaa00]

Like Chalnoth says, it's not that bad.

You can still install full IHV OpenGL ICDs and they can still expose full featuresets. The only difference is you can only use them in a fullscreen app, or with the fancy 3D desktop effects turned off.

If you're an artist or engineer running some hardcore 3D graphics or CAD package, you'll probably turn off the fancy 3D desktop effects, because you don't want to waste CPU/GPU resources on anything other than your 3D package.

If you're a gamer, you don't normally care about running games in a window anyway. So the fancy 3D desktop will turn off when your game loads, and turn back on when you exit the game. No biggie.

The only case this is a problem is if you want both the fancy 3D desktop effects AND a windowed OpenGL app that uses full extensions... and how often do you want that? Screensavers? Browser plugins?

 

[Bob]

The only case this is a problem is if you want both the fancy 3D desktop effects AND a windowed OpenGL app that uses full extensions... and how often do you want that? Screensavers? Browser plugins?

Multiple monitors?

 

[Proforma]

Because unlike D3D, OpenGL is forward compatible too. You can add new features much later in your development cycle, because you don't need to completely recode your graphics to work with DX n+1.


Have you actually built a game with a reasonably wide target audience, using D3D? It's worse than OpenGL. Not only do you need to check 57 cap bits, but even if two cap bits are set to indicate that some features are supported, the combination of those two cap bits together may not work. For some features (like 8 combiner stages), you need to set some completely unrelated state (that's normally invalid) to gain access to that feature.

You end up with plenty of card-specific code either way. At least, OpenGL makes it explicit.

yep, however cap bits won't be used by Vista's DX anymore. doh!

 

[Proforma]

You can't argue that part of the beauty of OpenGL is it's pick-up-and-go nature that DirectX will probably never achieve.

I have two words for you. "Managed DirectX" doh!

 

[yooyo]

Im 3D developer and Im developing software for relatime Motion Capture data processing.
Whole may work is based on OpenGL.

IMHO, it will be bad for whole world to let MS to design future 3D API and hardware.
Even more, D3D API have most worst design ever.
1. I just don't want to rewrite whole code to support new DX version and new features.
2. D3D API is under MS control. HW vendors cannot extend API to add support for features that was outside of latest D3D version.
3. It is designed only for games. There is no any additional interfaces for async texture transfer and async readback, genlock control, frame lock, frame/field control...
4. If MS decide to support only OGL 1.4 on Vista (no shaders, etc..) or if user have to turn off Aero just to use OpenGL app, im gonna drop MSN support and switch to another platform (Linux).

Jugoslav Stojanov
Centroid Motion Capture
www.centroidanimation.com