Question about DirectX and OpenGL.

Started by
51 comments, last by solinear 22 years ago
I''ve been looking into the possibilities of running both APIs at the same time on the same window. Haven''t tried any actual code yet, but here''s what I''ve seen so far:

The initialization of both APIs is seperate and does not appear to conflict. I''m not totally sure whether or not the APIs would fight for the device; this may depend on the specific driver. The primary problem is forcing both APIs to use the same back buffer. This mainly involves getting an hDC to the surface returned by IDirect3DDevice8->GetBackBuffer. I''m pretty sure this is possible, and if you ask D3D to Present(), it should swap the buffers without requiring a swap thru SwapBuffers(). But that''s just exploratory research. Would anyone care to follow up on this?

____________________________________________________________
Direct3D vs. OpenGL
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
Advertisement
Well, I started with D3D and then looked at OGL and at this moment the latter seems easier than the former. I have two major complaints about OGL, though. The first one is complete lack of debugging support: if you do something wrong, OGL sometimes return one of its half a dozen error codes (this is if you screw up in init or something of this scale) but mostly it will just silently draw nothing. D3D, on the other side, has the debug runtime that finds all kinds of bugs for me. The second one is the famous OGL extensions. Any way you look at it, you only need to write code once for D3D but at least twice for OGL if you plan on supporting both NV and ATI. Besides, being an NV owner, how am I supposed to test my program that uses ATI extensions? I see no such troubles with D3D.
---visit #directxdev on afternet <- not just for directx, despite the name
OpenGL and Direct3D will not co-exist in the same window. One reason for this is that some OpenGL drivers use DirectDraw internally to manages surfaces, and you will get nasty conflicts if you try to initialize D3D for the same window as well. There are probably alot more reasons why it won''t work.

It *may* work for *some* drivers, though you''re likely to have more problems than it''s worth.

A program can use both OpenGL and Direct3D as long as it''s not trying to use both at the same time (i.e. you can have the user choose which one to use and switch on the fly, etc.)
First, I would like to thank everyone for helping this be the longest OpenGL/Direct3D thread that has ever existed

I honestly wish that I had more questions...

It sounds like Direct3D is overall better and I guess I''ll have to ask what it''s drawbacks are now.

I''ve heard that it leaks memory like a screen if you''re not careful and very thorough. One thing to remember is that there is not always only one programmer, so one member of a team might build one part of it and another member does some other parts... this means that you''ve got people who are working with code that they didn''t write, so they''re not intimately familiar with (heard that DAoC has serious memory leakage issues where you have to actually restart every so often, mattering on how much RAM you have).

We know that the detriments to OpenGL is that the competing video card makers (Nvidia and ATI) can''t seem to keep their heads out of their butts long enough to cooperate and compromise and that largely ends up with OpenGL falling behind for the mostpart (though many of the features are hard to notice while you''re pushing 100k polygons/frame at 35 frames/sec or something like that).

Guess I''m just trying to figure out whether they actually is a preferred option. Obviously if you''re going to port over to Mac or *nix, OpenGL is pretty much the only way to go, but what if you''re not? There really isn''t a performance hit for Direct3D? I just think that games that I''ve run into running Direct3D end up looking like ass compared to the OpenGL games that I see out there right now.
>>I''ve heard that it leaks memory like a screen if you''re not careful and very thorough<<

d3d shouldnt be leaking memory perhaps the programs leaks memory.

>>OpenGL 2.0 will basically catch OpenGL up with where Direct3D is at right now<<

opengl2.0 is far advance of where d3d8 is now (check the opengl2.0 spec which can be gotten from 3dlabs), its more in line with d3d10

about speed?

technically opengl is the quickest (u cant argue against that, it has less overhead than d3d)

how can u see which of the 2 api''s is fastest?

fire up a program that does d3d+gl eg unreal tournament, serious sam2, tribes 2 engine ( i forget the name ) benchmark d3d +
opengl.
write your own simple demo (that does the exact same things)
once with d3d + once with opengl

remember ms made d3d8 (+ the card makers have to adapt their cards to that)
with opengl extensions the card maker can tailormake an extension that fits their card perfectly.
logically which one sounds like its gonna give the best results?

http://uk.geocities.com/sloppyturds/gotterdammerung.html
Proprietary extensions are all very well, but who can be bothered to write separate code for every make of card? I know I can''t. Roll on OGL2.0.

In terms of graphic quality, to me, OpenGL always looks much better than D3D, at least on the nVidia cards at I''ve used (TNT, Geforce 2 Pro, Geforce 3 Ti200). This is because, for some reason, almost all D3D games have very poor texture filtering, which makes them look much worse than most OpenGL games with trilinear or bilinear filtering.

I don''t know if this is caused by the nVidia drivers, the games themselves or Direct3D, but all D3D games I''ve seen have suffered from it, so I suspect it''s the drivers or D3D which is to blame.

____________________________________________________________
www.elf-stone.com

____________________________________________________________www.elf-stone.com | Automated GL Extension Loading: GLee 5.00 for Win32 and Linux

hey the threads still open
true it is a bit more work
but let me ask you are u doing this in your code

if (card_can_do_dot3_bumpmapping)
{
use it
}
else
{
do software fallback
}

+ if not, why not.



http://uk.geocities.com/sloppyturds/gotterdammerung.html
The if test probably isn''t a good design. What probably would be better is to find which extensions a card supports and then select an appropriate class to do the rendering, all rendering classes would be derived from one base class. If you wanna add new video card support , derive a new class for it.
"THE INFORMATION CONTAINED IN THIS REPORT IS CLASSIFIED; DO NOT GO TO FOX NEWS TO READ OR OBTAIN A COPY." , the pentagon
quote:Original post by zedzeek
hey the threads still open
true it is a bit more work
but let me ask you are u doing this in your code

if (card_can_do_dot3_bumpmapping)
{
use it
}
else
{
do software fallback
}

+ if not, why not.



http://uk.geocities.com/sloppyturds/gotterdammerung.html


That''s pretty much what I''m doing for the ARB or EXT extensions, but it isn''t always as simple as that. For instance, nVidia and ATi cards have completely different extensions for implementing pixel shaders. Given that I don''t have an ATi card, I''m forced to write code which will only work on an nVidia.

____________________________________________________________
www.elf-stone.com

____________________________________________________________www.elf-stone.com | Automated GL Extension Loading: GLee 5.00 for Win32 and Linux

If you''re having problems getting the different (ATI and nVidia) versions of code to play nice together, go check out this guy''s stuff:

http://esprit.campus.luth.se/~humus/

Check out the Game Engine. If you ask nicely he should send you the source code for the engine so that you can see how he got some of the vendor specific stuff to work in either the ATI series or nVidia series cards.

BTW, no... he won''t work on anybody''s project and please don''t ask him to. Nothing worse than saying "No I won''t" and then getting harassed by 50 people who think "but my project is different ".

This topic is closed to new replies.

Advertisement