Originally posted by glfreak:
Why then Croteam has decided to switch to D3D, and so does EpicGames?
Because they intend on directing their support towards xbox/xbox360, because that’s where the main market for generic, mundane first-person shooters is. There will also be lots of 360 to Vista ports, so it’ll make their life a bit easier.
It’s absolutely no indication of the quality of D3D. If you’ve ever used D3D in a commercial situation (I have), you’ll doubtless be more appreciative of OpenGL.
Direct3D Disadvantages in summary:
- No extensions
- Evolving very rapidly, but needs frequent dx updates to do that.
- Complex API
- Low level access to hardware caps
- Microsoft creation
- The batch problem
- Needs instancing
- Is made only for games
- Microsoft creation
- not portable, at least not legaly portable
OpenGL Disadvantages:
- Microsofts huge pile of $$$
There is nothing D3D has that openGL allready has on some level/Got it before d3d/does better/don’t need/finds useless.
D3D also doesn’t have quad-buffered stereo, which makes it useless for really, really, really good games - such as the ones we previliged few play in caves etc.
- Microsoft creation
- Microsoft creation
There’s no need for that in any serious discussion. Like Microsoft or not, the fact that they made it is ultimately irrelevant to the quality of the product itself.
- The batch problem
- Needs instancing
These are two halves of the same coin.
- Low level access to hardware caps
I don’t see any way in which that is a disadvantage.
Like Microsoft or not, the fact that they made it is ultimately irrelevant to the quality of the product itself.
well, yes, but quality is not the only criterion for choosing a particular product. i don’t want to cite from the bazaar and cathedral article here, but i think you’ll have to agree that it is not a good feeling to use an API whose standards are dictated by a single company.
[quote]5) Microsoft creation
9) Microsoft creation
There’s no need for that in any serious discussion. Like Microsoft or not, the fact that they made it is ultimately irrelevant to the quality of the product itself.[/QUOTE]sorry i couldn’t help myself.
[quote]6) The batch problem
7) Needs instancing
These are two halves of the same coin.[/QUOTE]Yes and no, instancing only tries to fix a bad design decition MS did and without it you get a small batch like problem, well higher cpu load anyway.
But not using it does not nessesarly create a lot’s of new batches.
[quote]4) Low level access to hardware caps
I don’t see any way in which that is a disadvantage.[/QUOTE]true, but it does add complexity and besides, an developer should not work on the hardware level, that’s the job for the drivers, not the API
[quote] [quote]4) Low level access to hardware caps
I don’t see any way in which that is a disadvantage.[/QUOTE]true, but it does add complexity and besides, an developer should not work on the hardware level, that’s the job for the drivers, not the API [/QUOTE]In ideal world where all hardware supports all api features (this will be, with small number of exceptions, the case of DX10) there is no need to know the hw capabilities. In current real world it is imho better if applications requiring performance (e.g. games) know that specific feature is not supported on current hw so they can use another way to implement some effect or disable effect entirely. It is much better if user gets fast game without effect instead of game with effect at sw emulation speed. Yes, you can measure performance of the rendering and disable features based on that however that is even more clumsy than the capabilities and you do not know for sure, unless you use many tests, why you are hitting the sw fallback.
Originally posted by zeoverlord:
[b]
- No extensions
[/b]
Extensions are both blessing and curse of the OpenGL.
The are blessing because they allow HW vendors to expose additional capabilities of the hw.
In current state they are also curse because each vendor has tendency to implement its own extensions to implement the same functionality.
For example use of hw capable of DX pixel shaders 1.1 In DX you write single shader and modulo driver bugs it should work on any card supporting at least pixel shaders 1.1 altrough it may not take full advantage of all capabilities of specific hw. In OpenGL you have to use several extensions to implement that functionality on different class of hw. NV_register_combiners + NV_texture_shader for GF4 class hw. ATI_fragment_shader for ATI8500 class hw. ARB_fragment_programs for cards of other vendors or future nVidia and ATI hw.
Generally for one thing DX contains mostly one, vendor independent, way to take advantage of it.
2) Evolving very rapidly, but needs frequent dx updates to do that.
Each update allows MS to improve the interface to match the capabilities of current generation hw dropping obsolette stuff from it and possibly simplyfying it in the process.
This also reduces chances of having too complex dependencies (e.g. what happens if new state foo is enabled together with old state bar) which may some drivers implement wrong.
3) Complex API
I would not call the current generations of the DX API too complex. If advanced features (not if you render only one cube) are used the complexity of having to use several different extensions in OpenGL to implement same functionality on different hw made the OpenGL api the more complex one in my opinion.
Oh, just thought of another one - OpenGL has a specification, and each extension is required to have a specification. There’s just a CHTML file with D3D, containing very scant details on how each feature works and how it affects other features. I frequently refer to the OpenGL spec to figure out problems I’m having in D3D!
Thanks for ur helpful comments.
D3D is much more suitable for games. (Its power is the ability to control the hardware caps and surfaces) DX is a package suited for games.
OpenGL is much more appropriate for CAD/Sim/Model/Anim tools. (General Purpose when the concern is to get polygons rendered)
Cheers!
D3D was developed for games :-/
I still don’t see why it is better for games though
As for extensions, they are a very positive feature beacause they provide an API evolution, kicking out things that don’t stick very fast.
glfreak, you have contributed nothing to this discussion, therefore your opinion is irrelevant. Go read some books, write some apps, then in a few years come back and start another thread like this.
No! This thread hopefully will awaken the ARB to make some improvements. OGL is becoming outdated!
Somehow I can’t take your seriously. Please tell where is openGL outdated, then we can speak about it. You weren’t able to show it till now.
Geometry shaders? Give me a break, there is no card that supports it and I am shure, we will get the extension for it as soon as it appears. Instances? No need. Streams? Interesting, but no real need. What else do you hav eon your mind…
The only one advantage of DX I can see it that it provides functionality before it is actually popular. maybe that is why new games choose DX, so they can experiment with itfor about two-three years till it becomes popular.
Originally posted by Zengar:
I still don’t see why it is better for games though
I assume that following this will be the reason.
- [li]Has unified support for shaders on PS 1.3 and 1.4 class HW. Many games must support that or even older cards so writing one shader that works on all PS capable cards is much simplier than writing several shaders using different extensions for different HW and different vendors.[]DX HLSL shader compiler can be relied upon because application uses the version it was developed with so the application knows what works and can incorporate workarounds for things, that may not work with that specific vesion.[]Had simple to use render to texture capability for long time.[]Had reliable vertex buffers long beffore OpenGL.[]Features are accessed trough one standardized interface instead several vendor dependent extensions (e.g. NV_texture_rectangle, EXT_texture_rectangle, ARB_texture_rectangle for texture rectangle support). Also many parts of interface are implemented by MS so this limits driver introduced bugs.[]Gives knownledge about HW capabilities and simple identification of HW and driver using hw assigned guids so application can create workarounds for specific HW/driver combination.[]Many HW vendors have at least somewhat usable DX drivers where theirs OGL drivers are terrible.
As for extensions, they are a very positive feature beacause they provide an API evolution, kicking out things that don’t stick very fast.
They are positive if there is one extension used by all vendors to implement some functionality. Not if there are tons of incompatible extensions that implement the same functionality.
Also if some extension ceases to be supported because it is considered obsolette, older programs that required it will have problem. In DX if that feature was required part (no capability bits to indicate that is not supported) of some version of the API it can not vanish in the future for programs using that version of the API. Of course unless that entire API version will become unsupported.
No! This thread hopefully will awaken the ARB to make some improvements. OGL is becoming outdated!
It is because of threads like this one that the ARB doesn’t bother reading anything in this section of the forums.