Which API is better?

OpenGL and Direct3D (contary to public opnion they exist in written form) specifications aren't worth the paper there written on if there is noway of checking the IHV keep to them.
Example : ARB_fragment_program
NVIDIA and ATI both have differing output with regard shadow maps. (NVIDIA claims ATI pushed through a change of spec that disadvantages there hardware)

At least when NVIDIA tried to change the Direct3D PS_2_0 spec, I had an outside organisation to shout at. Where would I have gone with OpenGL? Who do I go to when an IHV knowingly breaks the spec and refuses to fix it?

D3D vs OpenGL arguments are totally pointless, Its was ~8 years ago since I was involved in my first one, and as I really don't care which API I use (I prefer RedLine personally ) I'll duck out of this thread.

 

Implicit in my statement is stability, and consistency. And I disagree with you in any case. OpenGL's balance has always been toward flexibility. Just look at the extension mechanism.

 

Lol, I suppose then we should just use DX7 too. After all, we can't expect that users upgrade to the latest version of DirectX, can we?

Of course you can demand the user to upgrade his drivers. You can check the driver version at installation time and see if it's a known buggy one, and in that case ask the user to install a new one, like when your DX version is too old. Just place a working driver set on the game CD for all IHVs.

 

"More work for compiler authors", indeed. Compiler authors need to do more work. They need to reconstruct the information the MS compiler stripped away from the shader.

I would be more concerned about how long it will take them to come up with competitive hardware.

 

Right...but only for a handful of applications, each of which actually tends to have it's own "certification".

That's the difference between "professional" and consumer. Orders of magnitudes of a difference in terms of the number of applications, as well as the pace at which advances occur. (and therefor need to be controlled.)

As above. Far fewer apps to "examine / certify" with, and far fewer end users to deal with.

Wow....specially designed closed systems.

EXACTLY.

It has "transforphied", while at the same time maintained a level of backwards compatibility and support on a HUGE number of software and hardware implementations.

It took a centralized level of control to make that happen.

Right...slow moving.

Humus...you're just another developer who prefers the GL interface. Most do. That's fine, I take your word for it. This doesn't mean the GL structure as a whole is best for the consumer space.

 

So open standards isn't a good thing anymore? Now it's strong central control we want? Oh, how the times change.

 

Sigh....

How many times must I repeat myself. Let me say it again, but putting it another way.

I never said open standards aren't a good thing.

But depending on the target market, one single controlling authority (who takes input from the players) can be a better model than 'standards by committee.'.

 

I see standards by committee as being too combersome, too late and takiing a please everyone approach which doesn't always work e.g. JEDEC.

The MS DX approach is a good thing as their is plenty of input from developers and IHV's to ensure their product (DX) is used successfully and easily.

 

Ah but Democoder I think with DX8 and then DX9 MS has made a push in the right direction and still has the momentum to carry the standard forward. In fact I appreciate the slowdown that is predicted from DX9 to DX10.

Can you tell me was OGL2.0 'late.' I hope it is successful but almost every developer on the PC platform seems to have switched over to DX (for better or worse).

 

The GL's design by committe was so great, it wouldn't be behind DX in many repects, given the relative newness of DX relative to GL.

The ARB is design / approval by committee.

Again, spoken purely from a developer perspective. The pace at which MS improved and innovated DX over a short period of time, while maintaining compatibility is testament to MS's / DX design approach.

 

How, where, what? Direct3D has been behind the curve from since its inception until (excluding) DX8.
So you had this one release that was 'better' in one area and that then marks the abandoning of OpenGL in the games market? I beg to differ. GL has been under the pressure of mudslinging PR people rephrasing the old "Well, GL is not designed for games, but Direct3D was, you know" up to the point when they started believing it themselves. That's one of the two reasons Direct3D even exists (as in "survived this long"), the other reason being OpenGL itself. Without OpenGL, there would have been no foundation to 'borrow' the fundamental know how from (eg the already mentioned "DX7" hw t&l, but also more basic things such as texture sampling positions and filters, watertight rasterization, the whole combiner paradigm, stenciling, etc).

On the "DX9" techlevel, OpenGL offers the same shader functionality as Direct3D runtime and is less restrictive. High level compilation in DXG, pardon me, just went horribly wrong. There's no point in shipping DXG applications with high level code. Offline tools, that's all you get, albeit in a more complicated way.

That leaves us with the single apparent* benefit of using DX Graphics:
Pixel shaders at the NV2x/R200 tech level are sort of unified. Ie NV2x hardware capabilities were brutalized to put them just below R200, so that a vendor neutral PS1.1~1.3 could be defined. PS1.1 runs on R200 while in OpenGL there is no such common ground. R200 fragment shaders and NV_register_combiners/NV_texture_shader must be explicitly supported in seperate codepaths. This is just a reflection of reality, the hardware is vastly different after all.

From a 'business' pov this certainly makes DXG look more attractive. OTOH it tends to underexpose hardware, which equals performance loss

Add on top of that all the political issues that have spawned from this backwards compatible versioning scheme (3DMark2k1 "advanced pixel shaders"; PS1.4 in 3DMark2k3; PS2.0a anyone?). DX Graphics just isn't fair, particularly not so in the context of neutral benchmarks. Admittedly this is a side issue, but it didn't tilt my sympathy towards DXG.


*adding an ARB_fragment_program backend to my pet project took me eight hours, including debugging, validation and going final. The backend runtime-generates shaders from a rendering state vector and caches them in API objects via hash. Approx 10000 possible permutations. It's not that much work to support multiple paths.

 

That's what I call a closed standard. Centrally enforced, and in this case from a third party.

 

This argument has been heard in all times and have been false pretty much all the time. Certain features have appeared in DX first, but they are fewer than the other way around.

Wrong. It's design by workgroup, approval by committee. Vendor A does initial research, takes it to the ARB, ARB decides to go forward, creates a workgroup with people from vendor A,B and C. These work together to design the extension, usually beginning from the original draft show to the ARB. This work is done in the workgroup and outside the ARB. Once the workgroup is done with their work, it's taken back to the ARB for approval.

DX has not "improved and innovated" particularly much over "a short period of time". Even if would have, I still would have preferred the API that was for most parts done right from the beginning. It took them until DX7 before it was anywhere close to GL. And I'm still waiting for MS to fix some stupid design choices such as texture upload by locking and to fix the default state to something that makes sense.

 

Has anybody brought up this yet?



From one of NVidia's presentations at GDC 2003 -- "Batch, Batch, Batch"

 

Yes, nVidia recommends sending a couple thousand triangle per batch.

And the poor DirectX performance with few triangles per batch was the reason why some of the first DirectX T&L games (*cough* Test Drive *cough*) performed poorly.

 

Most publishers won't allow us for legal reasons...

Its not for trying I can tell you...

The basic problem is the change that some user installs a driver of a game CD, Office runs badly and then blames the publishers. So you either left saying "Install this driver to make this game work, but if it breaks your machine don't blame us", which the legal departments don't like. Its also increase support calls, each support call wipes out the entire profit from the sale of a PC game, publisher will do almost anything to reduce the chance of the user phoning up and saying 'this game doesn't work'.