If Doom 3 had been written in D3D....

[Xmas]

NVidia had texture crossbar since the Riva TNT.

 

[Ostsol]

NVidia had texture crossbar since the Riva TNT.

You sure? NVidia's own documentation lists support for that as starting with the NV1x series.

http://www.nvidia.com/dev_content/nvopenglspecs/nvOpenGLspecs.pdf

 

[Scali]

NVidia had texture crossbar since the Riva TNT.

Which brings us back to the point of vendor-specific code vs generic support.
The ARB solution wasn't available until Feb 2001, by which time Direct3D already offered a superior generic solution (and the hardware itself was also more advanced than register combiners already).
It's usually like that.

 

[Xmas]

NVidia had texture crossbar since the Riva TNT.

You sure? NVidia's own documentation lists support for that as starting with the NV1x series.

http://www.nvidia.com/dev_content/nvopenglspecs/nvOpenGLspecs.pdf

"ARB_texture_env_crossbar - see explanation"

NVidia does not officially support this extension because it requires a certain default behavior when a texture is disabled. NVidia had an own extension before (NV_texture_env_combine4) which can be used in exactly the same way (and offers more), but requires another default behavior. Unfortunately, the driver has no way of knowing which extension you had in mind when you use it, because they only specify that you can pass existing constants to existing functions, but in a way that wasn't allowed before. You can still use it if you wish to but "ARB_texture_env_crossbar" is never exposed in the extension string. It has been promoted to a core feature with OpenGL 1.3, with the modification that the behavior when a texture is disabled is now undefined.

However, NVidia does support a crossbar in both NV_texture_env_combine4 and NV_register_combiners extensions.

 

[Xmas]

NVidia had texture crossbar since the Riva TNT.

Which brings us back to the point of vendor-specific code vs generic support.
The ARB solution wasn't available until Feb 2001, by which time Direct3D already offered a superior generic solution (and the hardware itself was also more advanced than register combiners already).
It's usually like that.

Well, DirectX8 wasn't available until Nov 2000, and the first hardware supporting that "superior generic solution" was GeForce3, launched Feb 2001 and available months later.
There is no crossbar in FF DX.

 

[KimB]

You can still use it if you wish to but "ARB_texture_env_crossbar" is never exposed in the extension string. It has been promoted to a core feature with OpenGL 1.3, with the modification that the behavior when a texture is disabled is now undefined.

However, NVidia does support a crossbar in both NV_texture_env_combine4 and NV_register_combiners extensions.

Strangely, EXT_texture_env_crossbar is in the extension string, though I don't see it in the registry.

 

[Humus]

Has a GL_EXT_texture_env_crossbar ever existed? Google doesn't turn up a single hit ...

 

[Ostsol]

Based on the ARB meeting notes, it looks like ARB_texture_env_crossbar was an ARB project. The previous proposed name was ARB_texture_env_multi_fetch.

 

[Scali]

There is no crossbar in FF DX.

I know, FF has basically been untouched since DX7 anyway. My point was: since DX already had programmable shaders at that time, who cares about FF? Now let's look at when there was a generic solution for GF3's shaders in OpenGL... Oh, never!

 

[KimB]

Since the GF3 was the only card to supports its type of shaders, I'm not sure it matters all that much that there were no ARB extensions for shaders at that time.

 

[Rolf N]

There is no crossbar in FF DX.

I know, FF has basically been untouched since DX7 anyway. My point was: since DX already had programmable shaders at that time, who cares about FF?

People writing code that must support cards below the NV2x class care. Most of these cards are much more capable than you might know, if all you ever used to program them was DX7.

Now let's look at when there was a generic solution for GF3's shaders in OpenGL... Oh, never!

Bleh. Let's look at when you could use the GF3's full potential under DirectX Graphics ... oh, never!

 

[Scali]

Since the GF3 was the only card to supports its type of shaders, I'm not sure it matters all that much that there were no ARB extensions for shaders at that time.

What happened to Radeon 8500, Parhelia, Xabre?
Yes, all ignored by OpenGL, lovely.

 

[Scali]

People writing code that must support cards below the NV2x class care. Most of these cards are much more capable than you might know, if all you ever used to program them was DX7.

Is this where you are going to lecture about vendor-specific register-combiner extensions?
I don't care.
I have my hands full writing 1 FF path, 1 ps1.1 and one ps2.0 path.
In OpenGL this would cost way more time and money, so it's not an option for many developers. In fact, only idsoftware seems to consider it an option... And I can't say that the result is significantly better than it would be with D3D, to be honest.

 

[Saem]

What happened to Radeon 8500, Parhelia

ATI and Matrox since the R100 days, IIRC, worked out a standard between the two of them in hopes of getting it into the core, IIRC, they were fairly successful.

 

[KimB]

What happened to Radeon 8500, Parhelia, Xabre?
Yes, all ignored by OpenGL, lovely.

The Radeon 8500 had its own OpenGL extensions for shader support.

The Parhelia and Xabre are pretty much non-issues for gaming.

 

[Xmas]

There is no crossbar in FF DX.

I know, FF has basically been untouched since DX7 anyway. My point was: since DX already had programmable shaders at that time, who cares about FF? Now let's look at when there was a generic solution for GF3's shaders in OpenGL... Oh, never!

We're talking about a time when there was no hardware with programmable shaders available for months to come. In this context you seriously ask who cared about FF?

And if you count all the caps checking and workarounds for missing caps, do you really think "having three rendering paths" is an accurate description of what's going on? How many officially supported paths does Doom3 have again?

 

[Rolf N]

People writing code that must support cards below the NV2x class care. Most of these cards are much more capable than you might know, if all you ever used to program them was DX7.

Is this where you are going to lecture about vendor-specific register-combiner extensions?

No.
This is when you get a lecture on this and its grandpa. I trust you know how to use Delphi3D's online db to check what level of support the ARB version has, and since when? And while your at it, check ARB_texture_env_crossbar as well.

I don't care.
I have my hands full writing 1 FF path, 1 ps1.1 and one ps2.0 path.

A single FF path means no EMBM on Radeon 7xxx, no DOT3 for Geforce2MX etc, right? Fine.
How many code paths do you suppose you'd end up with in an OpenGL renderer, given your "I don't care" attitude about low end hardware support? I'd say four. Your three paths plus one for R200. Oh the horrors.

 

[Scali]

And if you count all the caps checking and workarounds for missing caps, do you really think "having three rendering paths" is an accurate description of what's going on? How many officially supported paths does Doom3 have again?

Yes, I only code 3 paths myself. FF is aimed at GeForce. Any Radeon (or Extreme Graphics, brrr) can handle that (I make sure of that by side-stepping some of the pitfalls, like non-mipmapped cubemaps), and there isn't any other non-shader card which can run DX9 code at all, I believe. It's not significant enough for me to support anyway.

Let's see... Doom3 has... NV1x, NV2x, NV3x, R200 and ARB. That's two more... Worse than that, R200 and NV2x are almost too close, as are NV3x and ARB.
(Yes I know NVIDIA basically copy-pasted NV3x path into their drivers, so Doom3 no longer contains it in the final... but that doesn't matter, since it was developed, so time was spent on it).
Oh, and do note that it doesn't support Radeon 7x000 or Extreme Graphics at all, while my code generally does. So Doom3 is less compatible than my stuff aswell, even though it has 2 paths more!

 

[Scali]

This is when you get a lecture on this and its grandpa. I trust you know how to use Delphi3D's online db to check what level of support the ARB version has, and since when? And while your at it, check ARB_texture_env_crossbar as well.

I know about the register combiner thing, but there is quite little that it can do that DX7+ FF can't do (which actually works on more than one card at a time anyway), if you ask me (okay crossbar, but how useful is that anyway?).

A single FF path means no EMBM on Radeon 7xxx, no DOT3 for Geforce2MX etc, right? Fine.
How many code paths do you suppose you'd end up with in an OpenGL renderer, given your "I don't care" attitude about low end hardware support? I'd say four. Your three paths plus one for R200. Oh the horrors.

I don't use EMBM in general. If I need it, there will have to be an extra path. But generally I use dot3, if bumpmapping is required, it works on all cards anyway. And since when does GeForce2MX not support DOT3? Afaik all GeForce2's are equal (the MX is listed to have GL_ARB_texture_env_dot3 anyway, so no doubt it has DOT3 in D3D aswell), and GeForce256 and 4MX are also equal.

And yes, an extra path is 33% more work, so no thanks. If you pay me 33% extra, I'll consider it. Else, stop your silly OpenGL zealotry on me. To me, OpenGL is a waste of time and other resources (having to check on a website to see what extensions are supported where, etc... Here's a nice one for you... I do code OpenGL you know (CAD-related stuff)... and recently I ran into a G450 with no pbuffer support... What do you do then? Same G450 supported render-to-texture and stuff fine in D3D btw. Another reason not to use OpenGL, it simply isn't supported as widely or as well as D3D).

Besides, I'm not the only one who has made this choice. Carmack is basically the only moron still coding OpenGL. And even he will convert eventually. Perhaps he already has... Doom3 is done, and he did say at one point that his next engine would be in Direct3D.
So go lecture all the other game developers first, I don't really care myself. I chose Direct3D for good reasons, and I have worked with OpenGL and Direct3D long enough to know that Direct3D is my favourite, for many (good) reasons.

 

[Xmas]

And yes, an extra path is 33% more work, so no thanks. If you pay me 33% extra, I'll consider it. Else, stop your silly OpenGL zealotry on me. To me, OpenGL is a waste of time and other resources (having to check on a website to see what extensions are supported where, etc... Here's a nice one for you... I do code OpenGL you know (CAD-related stuff)... and recently I ran into a G450 with no pbuffer support... What do you do then? Same G450 supported render-to-texture and stuff fine in D3D btw. Another reason not to use OpenGL, it simply isn't supported as widely or as well as D3D).

If you think another rendering path is 33% more work, then your choice of D3D is just fine. D3D has a lot of advantages, no doubt, but if you kept your "don't care about certain features" (EMBM) attitude, you could also use OpenGL and not care about a lot of extensions.

What do you do when you run into a card with no crossbar support in D3D, although it supports it in hardware (and OpenGL)?