EXT_packed_depth_stencil released

OpenGL OpenGL: Advanced Coding
41

Eh? I didn’t give any reason why d3d only works properly with large batches, I merely stated that it, as it stands in the major implementations, is definately cpu intensive. The reasons for this are irrelevant to the developer. I’ve measured the differences between the two API’s with real world data, and d3d is significantly slower. It’s comparable with opengl with larger batches, however.

D3D is trying to be object oriented (Common Object Model), it has a notion of interfaces (d3d, d3ddevice), it has a notion of objects (texture objects, vertex buffer objects, index buffer objects, surface objects etc.etc). So, it works in an object-oriented way as it stands, so why so many enums? Every single state is an enum, every single state has just one parameter, which is a 32bit integer…things like fog range values have to be macro-magic’d into 32bit integers in order to fit in with this grand design. What the hell is wrong with having a function for every state? It’s not like there’s hundreds of states. Then you can be type-safe, then you don’t need to look up in a table for the attributes of that particular object/state. If you’ve got the freedom to re-invent your entire interface with every revision, then it absolutely should be completely object-oriented, because we’re dealing with objects all the way down the (pipe)line.
Why, specifically, do you believe object-oriented design doesn’t belong in a low level API?
Low level doesn’t necessarily mean straight C, you know.

42

The reasons for this are irrelevant to the developer.
Actually, the reasons are quite relevant for the developer. If the developer were giving up performance without getting anything in return, then D3D would have problems. However, developers are getting something for that; they get more stable drivers (thus less testing and therefore more time can be spent on more important things). Just as an OpenGL developer can expect more driver instability, but they can also expect better overall performance.

D3D is trying to be object oriented (Common Object Model), it has a notion of interfaces (d3d, d3ddevice), it has a notion of objects (texture objects, vertex buffer objects, index buffer objects, surface objects etc.etc).
OpenGL has many of those same objects, and yet nobody would even consider calling it object oriented. And COM does not imply OOP; it is a language-neutral mechanism for communicating between two different concepts. Just because the word/concept “object” is used does not imply that OOP is intended.

43

COM is of course an object-oriented concept, your interpretation of it is just its main motivation (and the blurb on the box).

Also, OpenGL should abstract it’s objects using interfaces too, but it’s current API is much clearer than D3D, it’s type-safe (glFogfv expects a float, no unsafe macros needed). It’s also pure C, and has to maintain backwards compatibility (see my point about d3d’s freedom to re-invent itself). But opengl is a C programmers interpretation of object-orientation.
Direct3D has the opportunity every year to sort this mess out, but it never seems to.
I’m sure there’s a very good reason, but nobody has so far given an explaination.