Subject: Re: [boost] boost::directx?
From: Carlos Rafael Giani (e0325834_at_[hidden])
Date: 2009-06-09 07:02:07
> Christian Schladetsch wrote:
>> That simply isn't true, unfortunately. DirectX and OpenGL have different
>> abstractions for the same hardware, and what's worse is that the hardware
>> itself is changing even faster than the API's that access it.
>> That is far different to the API's that deal with threads. To make
>> worse, OpenGL is a few generations behind DirectX (sorry, but it's true),
>> and the gap is only increasing with Geometry Shaders.
>> The reality is that DirectX provides the best API to use hardware, OpenGL
>> wont and can't compete at that level because unlike DirectX, OpenGL is
>> driving the hardware industry.
> Wasn't that stuff like Ogre3d do somehow.
> That's ages i didn't dip into these so take this question as a real
> naive one for the sake of the
- pixel formats supported by one API but not by the other (Direct3D: YUV
textures, OpenGL: latc compression, at least I'm not aware of a D3D
- buffers: OpenGL Buffer Objects and Direct3D Buffers work differently,
and allow for different semantics
- render-to-texture differs significantly between the two (OpenGL FBOs
allow have many more features than their D3D equivalents)
- Direct3D10 unifies all types of buffers, OpenGL 3 doesnt
- Render-To-Texture in D3D understands (0,0) as being the upper left
corner, in D3D it is the lower left one
- Direct3D shaders and OpenGL ones have different, incompatible
approaches (D3D knows no shader linking for example)
- Direct3D uses vertex declarations, OpenGL uses pointers (which
actually are offsets when buffer objects are used)
This is a small excerpt of the differences. There are more subtle ones,
such as locking flags for memory mapping allowing more fine-grained data
transfers in D3D.
The problem is that the only feasible way is a lowest common
denominator, both in terms of features and performance. To use the
graphics hardware best, you must use API specific functions.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk