If Doom 3 had been written in D3D....
- Thread starter micron
- Start date
You sure? NVidia's own documentation lists support for that as starting with the NV1x series.Xmas said:
http://www.nvidia.com/dev_content/nvopenglspecs/nvOpenGLspecs.pdf
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.
"ARB_texture_env_crossbar - see explanation"Ostsol said:
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.
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.Scali said:
Bleh. Let's look at when you could use the GF3's full potential under DirectX Graphics ... oh, never!Scali said:
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.
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?Scali said:
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?
No.Scali said:
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.
A single FF path means no EMBM on Radeon 7xxx, no DOT3 for Geforce2MX etc, right? Fine.Scali said:
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.
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!
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?).
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.
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.Scali said:
What do you do when you run into a card with no crossbar support in D3D, although it supports it in hardware (and OpenGL)?
