PDA

View Full Version : OpenGL or DirectX



KraKRaZoR
06-13-2002, 11:17 PM
I was wondering which one of those(OpenGL or DirectX) are faster? What are their weaknesses and strengths? and which one is easier?

KraKRaZoR
06-13-2002, 11:36 PM
it's obviuos that directx is harder... but is opengl faster than directx or is it the other way around? is learning directx more beneficial than opengl?

hkyProgrammer88
06-13-2002, 11:49 PM
Which ever API current hardware supports (the best) will be faster. I think OpenGL is very beneficial to learn because it is portable to many platforms and it is not hardware specific (ie: Super computers might use OpenGL for graphics). DirectX I think is specific to PCs and Xbox and is most likely faster (now) on those platforms because current hardware is designed specially for it (with help/incentive from Microsoft).

In closing, my opinion is that OpenGL is a better structured high performance graphics API supported by many architectures, while DirectX is combersome and designed specifically for the PC and Xbox architecture.

Robbo
06-14-2002, 12:20 AM
I think the above is correct, but, for example, you will find that NVIDIAs implementation of OpenGL is very high quality. Portability is also an issue. The best thing I've found is that its just so quick\easy to pick up and learn. You can start running right away. This is good for productivity.

Phobeus
06-14-2002, 12:23 AM
IMAO speed isn't really made by the API, in fact opengl is much easier to learn than D3D (i tried both over longer times)...

the time you spend in learning D3D, you shall use for OpenGL to learn good optimation methods to speed things really up http://www.opengl.org/discussion_boards/ubb/wink.gif

dabeav
06-14-2002, 04:34 AM
Ah the classic OpenGL vs D3d debate. I definatly prefere OpenGL and Ill tell you why. First its very very easy to learn. It is very intuitive when you are a newby, and very robust when you are an oldby. There is nothing that OpenGL cannot do that d3d can. (ofcourse you may have to use extensions). Also alot of people debate over OpenGL vs DirectX. Which realy cant be done, cause directx is a series of APIs. handeling input, and sound, and such. Well in that catagory i pull these out. OpenGL is graphics, OpenAL is audio, OpenIL is for image loading, GLut is great for input. And ya know what, they are all OpenGL based syntax, so its very very easy to learn them all. And they are all compleatly platform independent. Which in my mind is much more important than any thing else. Because even though Windows is on top right now, dosnt meen it will be there for ever. There is a very nice version of Linux comming out soon called Lindows. Which, (i feel) will take a very large hold of the market, and Mac is making a comback. To leave these OSs out of your possible money circuit, is simply stupid. I mean that is like selling only chacolate milk in a store. Even though it is a much larger piece of the market, strawberry milk is still making money. You want to start off with the biggest piece of pie. So you get the most bang for your buck. That is why I use OpenGL.

Robbo
06-14-2002, 06:14 AM
dabe, I like the mixed metaphor (Milkshake and Pie)


http://www.opengl.org/discussion_boards/ubb/wink.gif

[This message has been edited by Robbo (edited 06-14-2002).]

dabeav
06-14-2002, 07:53 AM
Yeah, thats why i dont code when im hungry. TOO many variables start to look like this, const double PIE = 3.1416;
int lemon;
int lime;
char ImSoHungry;
bool NeedFood = true;
bool MmmmmmChoclate;

(by the way the bool NeedFood = true; is at the top of the engine im working on now, its set that when i compile, if a certain time has passes, the program simply outputs, ERROR, ERROR, GO EAT NOW.)

rpxmaster
06-14-2002, 09:42 AM
On 06-14-2002 01:17 AM, a contributor named KraKRaZoR made the following remark:
I was wondering which one of those(OpenGL or DirectX) are faster?

Actually, it pretty much depends on which operating system you're using, and in some areas, which version of Windoze you're using. True, Direct3D programs'll prolly run faster than OpenGL apps when you're using Windoze, but when you're using Linux or anything else...well, have fun getting your D3D app to compile.

It has come to my attention recently that on more recent versions on Windoze, the operating system may actually limit the refresh rate of your monitor, depending on whether you're running a D3D or OpenGL app. When you're running a D3D app, your monitor can run no faster than 75 frames-per-second, or 75Hz; on OpenGL, it's 60Hz.

This has nothing to do with OpenGL in general, though. This is Microshaft's fault; they coded this fix into their own operating systems. You, as a developer, shouldn't be too concerned about this though. If your graphics card drivers allow you to manually adjust your monitor's refresh rate, or if you can code a feature into your program that allows the user to manually adjust it, then your monitor can run faster than 60Hz when you run your program.

I'm only aware of this happening on Windoze XP (and I believe Millennium as well, Longhorn? prolly). But this is one of the only reasons where I can see Direct3D running faster than OpenGL. Other than that, they're about the same.


On 06-14-2002 01:17 AM, a contributor named KraKRaZoR made the following remark:
What are their weaknesses and strengths?

OpenGL:
Strengths:
*The API is easier than hell to learn
*It's platform independent
*You can use it with just about any popular programming language
*It works with almost any compiler, and the headers should already be included

Weaknesses:
*Doesn't support loading any file formats

Direct3D:
Strengths:
*Supports loading different image formats
*Supports .X format for loading 3D models, which in turn defeats the purpose of writing your own parser and learning how the file format works

Weaknesses:
*It's harder than hell to learn
*It only works on Windoze
*You can only use it with C++ and VB, or the last time I checked (don't know if they threw in Pascal, C#)
*Arguably, only works on Microshaft compilers (Visual)
*The SDK's a friggin' 140MB download



On 06-14-2002 01:17 AM, a contributor named KraKRaZoR made the following remark:
and which one is easier?

Obviously, OpenGL. Not is the API easier to learn, but they don't have to release new versions of the API as often as Microshaft does with DirectX. OpenGL is currently on its 1.3 version, with a 2.0 pending; DirectX, on its 8.1, and OpenGL is a couple years older than DirectX. The problem is, every time they release a new version of their API, you have to relearn the whole damn thing. This is where OpenGL is easier to learn and beneficial, because you don't have to relearn it as often.

[This message has been edited by rpxmaster because lists and UBB Code don't mix real well]

[This message has been edited by rpxmaster (edited 06-16-2002).]

Deiussum
06-14-2002, 10:31 AM
It has come to my attention recently that on more recent versions on Windoze, the operating system may actually limit the refresh rate of your monitor, depending on whether you're running a D3D or OpenGL app. When you're running a D3D app, your monitor can run no faster than 75 frames-per-second, or 75Hz; on OpenGL, it's 60Hz.


Huh? Under XP, I run both with a monitor refresh rate of 85hz (the best my monitor can do at 1024x768), and have no problems. Also, for both there are ways to disable the vertical sync, so your app can actually run faster than the monitor can technically keep up.

I wasn't going to get into yet another D3D vs. OGL debate, but...

1. Which one is faster seems to depend on the hardware vendor. In my experience, nVidia generally has faster OGL drivers than D3D, though lately they seem to have been getting much closer in speed.

2. Learn which ever one you like the looks of first. They are both similar enough now that once you learn one, the other is easy to pick up.

rpxmaster
06-14-2002, 07:18 PM
True enough, 'which one computes faster' is an entirely different mantra as opposed to 'which one is screwed more by the operating system, in terms of monitor refresh rate'. However, it is a thing to be aware of if you're writing world class 3D Windoze apps, but not in determining whether OpenGL is better than Direct3D. Of course, if you're using pretty damn decent video card drivers, or if you know how to work around it yourself, then you'll most likely not even notice it. It'll work around the fix, and you won't even know it existed. This is a thing to keep in mind for users who don't give a damn which drivers/card they're using, or those who have to run their 3D apps in software mode, and that's why I bothered to bring this up. Besides, it's really annoying the hell out of me that Microshaft would put this fix in.

As of me, I chose OpenGL myself because I can do a hell of a lot more with it than I can with Direct3D--as in terms of portability. I can write programs for Linux, Mac, Windoze, etc., therefore I'm not limited to the huge, 'Microshaft-only' part of the software industry.

06-14-2002, 08:25 PM
Let this horse die.

Do a search and read the umpteen posts just like this.

OpenGL can not compare to DirectX because DirectX has full multimedia capabilities. How MANY TIMES MUST IT BE SAID THAT OPENGL IS JUST GRAPHICS. Cripes. You mean Direct3D. You say I am niggling well programming takes attention to detail so get used to it.

Bottom line; OpenGL and Direct3D performance is directly related to how well you write it. Write well and you'll get similar performance.

MrShoe
06-15-2002, 01:47 AM
rpxmaster... errr, you said something about OpenGL being able to load only 24bit bmp files and 24-32 bit targas?? err, opengl doesnt do the loading of different file formats. You have to code the file loading routines yourself... It is true that opengl can only taje power of 2 texture dimentions, but thats a graphics card issue, and as far as i know d3d can also only take power of 2 textures.

Just outta interest, if i was looking forward to a carreer in the game industry, would d3d or opengl suit? i know im prolly gonna be told that both should be learnt, but...

rpxmaster
06-15-2002, 02:19 PM
Ne'er mind, I was thinking of NeHe's code, and glaux, as opposed to DevIL. However, the point that I was trying to make was this: If you think Direct3D is 'better' than OpenGL because it can support loading different file formats and OpenGL can't, then you're just proving that you're an idiot. Anyone knows that they can write an image parser better than Microshaft can, and they should to suit the needs of their program, or use something like DevIL to do the job.

Now, to answer your question, MrShoe, you should learn OpenGL if you were looking forward to a career in the game industry, in general. You should learn Direct3D if you were looking forward to writing Windoze specific game titles *g*.

Actually, I've seen some good games that can run using either OpenGL or Direct3D, so it might not hurt to learn both anyways.

Anyways, I have a question now: Does OpenGL work on XBox? I've never figured this one out.

[This message has been edited by rpxmaster (edited 06-16-2002).]

MrShoe
06-16-2002, 12:47 AM
I write my own image parsers, i have this thing about using code that i dont understand, so if im gonna use some1 elses code at least i always make sure i can understand it and reproduce it....
What games can use both OpenGL and DirectX?
Dont say unreal coz thats written in the Glide api, the actual code that is...

rpxmaster
06-16-2002, 02:52 PM
On 06-16-2002 02:47 AM, a frequent contributor named MrShoe made the following remark:
What games can use both OpenGL and DirectX?
Dont say unreal coz thats written in the Glide api, the actual code that is...


...I thought Quake3 used OpenGL and DirectSound *grin*

Seriously, I know of a couple titles from the top of my head that can do this. Homeworld and Homeworld: Cataclysm, both by Sierra, may draw using either OpenGL or Direct3D. On my machine, they both use hardware rendering in either mode, and I use an nVidia GeForce2MX.

I'm pretty dang sure it is not written using the Glide API, since, when ran in OpenGL mode, they both use software rendering when you're using a Voodoo3 card.

[This message has been edited by rpxmaster (edited 06-16-2002).]

MrShoe
06-16-2002, 06:55 PM
There is a difference between rendering in Direct3D and OpenGL, and actually writing the code in one. Coz i dont see how you can write the code for both unless you actually do 2 calls for every function, say one for glTranslatef() and one for the equivalent in Direct3D, but hey, this is a bit off topic.

rpxmaster
06-16-2002, 07:57 PM
I believe they used both APIs to do these games, but I'm only 95% sure about this. If you render in one mode, and compare that to the other one, there is a slight, but noticeable difference, in situations like how they set up the ortho screens in both modes, and how they set up the viewport when you go to your desktop, and then back into the game. I assume it is possible to do two calls for every function, the one for OpenGL, and the one for Direct3D, but as for myself, I don't want to be the guy doing this.

Is it beneficial to learn both OpenGL and Direct3D? Probably, but I don't understand why you would even have to learn Direct3D, anyways. If you're in the game industry, and the laborers expect you to know Direct3D, then you might as well learn it. As for myself, I can do just fine without it.

Deiussum
06-17-2002, 04:51 AM
True enough, 'which one computes faster' is an entirely different mantra as opposed to 'which one is screwed more by the operating system, in terms of monitor refresh rate'.


Sorry, but I have never seen this mythical refresh rate limit you speak of. Without doing anything special like turning off vsync, both my OpenGL apps and my DirectX apps can run at the 85hz refresh I have my monitor set at. Sounds like another conspiracy theory of the anti-MS camp to me.

CopyCat
06-17-2002, 10:55 PM
Direct3D can't load files.
It's done by poorly optimised and stupid helper lib D3DX.
And when you use D3DX to load stuff ( textures etc ) all the stuff is hidden in interfaces...so to acces the core D3D stuff you will suffer http://www.opengl.org/discussion_boards/ubb/smile.gif
OpenGL rocks , ogl2.0 will rock even more http://www.opengl.org/discussion_boards/ubb/smile.gif
And besides that....D3D ( as whole DX ) is COM based....that means...only ugly C++ ( or VB but who uses it http://www.opengl.org/discussion_boards/ubb/smile.gif)) ) - and ogl on other hand...is 100% procedural..so basicly any language can support it http://www.opengl.org/discussion_boards/ubb/wink.gif

Robbo
06-18-2002, 12:44 AM
"It's done by poorly optimised and stupid helper lib D3DX"


Thats the most fantastic damning of D3DX I've heard so far in a single sentance http://www.opengl.org/discussion_boards/ubb/wink.gif

Questions Burner
06-18-2002, 01:11 AM
Conclusion had been made, OpenGL is better than Direct3D!

ScottManDeath
06-18-2002, 01:42 AM
Hi

there is a simple workaround to avoid running only at 60hz refesh rate, just before setting the screen resolution enumerate all display modes and chose that with the highest refresh rate. So you don't have to worry about the bug.

DEVMODE dm;
memset(&dm, 0, sizeof(dm));
dm.dmSize = sizeof(DEVMODE);
int mode=0;
vector < DEVMODE> modes,new_modes;
vector < DEVMODE>::iterator mode_it;
while(EnumDisplaySettings(NULL,mode++,&dm))
modes.push_back(dm);
if(modes.size()<1)
{
CriticalError("found no valid display settings");
return;
}

for(mode_it=modes.begin();mode_it < modes.end();mode_it++)
{
if( (mode_it->dmBitsPerPel==bits)&&(mode_it->dmPelsWidth ==width)&&
(mode_it->dmPelsHeight==height))
{
new_modes.push_back(*mode_it);
}

}

if(new_modes.size()<1)
{
CriticalError("invalid resolution");
return;
}
m_window.m_devmode=dm=new_modes.back();
m_window.m_devmode_valid=true;
m_window.m_bits=dm.dmBitsPerPel;
m_window.m_width=dm.dmPelsWidth;
m_window.m_height=dm.dmPelsHeight;
printf("entering fullscreen mode : %i x %i x %i @%i hz\n",m_window.m_devmode.dmPelsWidth,m_window.m_devmode .dmPelsHeight,m_window.m_devmode.dmBitsPerPel,m_wi ndow.m_devmode.dmDisplayFrequency);
ChangeDisplaySettings(&dm, CDS_FULLSCREEN);

Bye
ScottManDeath

rpxmaster
06-18-2002, 10:06 AM
Ahh I knew there was also a way to work around it in code, but I didn't know what it was. Thanks a whole lot, ScottManDeath.

Jeeeez
06-18-2002, 12:36 PM
Must not forget the most important difference:

D3D has only 3 letters!!!!!!!!
Therefore...it is much easier to spell!!!!!
http://www.opengl.org/discussion_boards/ubb/tongue.gif http://www.opengl.org/discussion_boards/ubb/tongue.gif http://www.opengl.org/discussion_boards/ubb/tongue.gif http://www.opengl.org/discussion_boards/ubb/tongue.gif

ffish
06-18-2002, 05:26 PM
Deiussum,

The XP refresh rate limitation is a known issue (although Microsoft probably doesn't acknowledge it). OpenGL games played under XP are limited to 60Hz. My XP Pro does run at 85Hz for normal Windows operation, but when games switch to fullscreen modes, they switch to the lower refresh. I can confirm this happening on Jedi Knight II and Soldier of Fortune II, the only two games I have installed since I switched to XP.

Luckily on Q3 based games, you can type r_displayRefresh x at the console where x is the desired refresh rate, then vid_restart. I looked at registry solutions when I learnt about this problem but there aren't any currently AFAIK. You should find information about the problem via google, I guess. e.g. '"windows xp" "refresh rate" 60Hz' gives heaps of links, as well as some limited fixes.

IIRC, I learnt about the problem initially on the advanced board (not sure, though). God knows why Microsoft introduced this limitation to the OS. Hopefully future service packs will fix it.

rpxmaster
06-18-2002, 07:00 PM
On 06-18-2002 02:36 PM, a frequent contributor named Jeeeez made the following remark:
D3D has only 3 letters!!!!!!!!
Therefore...it is much easier to spell!!!!!

...uhmm, '3' is NOT a letter, least the last time I checked *grin*


On 06-18-2002 07:26 PM, a frequent contributor named ffish made the following remark:
IIRC, I learnt about the problem initially on the advanced board (not sure, though). God knows why Microsoft introduced this limitation to the OS. Hopefully future service packs will fix it.

Knowing Microsoft, I don't think they'll ever release a fix for it, or acknowledge it in the first place--they claim it's a video driver's issue, since they do have the ability to override the limitation if they choose to put that option in. Microsoft has always been trying to kill off their competitors--Java, Mozilla, etc--by doing weirdness to their operating system, and now they're trying to take out OpenGL. Even with Longhorn, seriously, have you ever ran a D3D and an OpenGL app simultaneously? It's not something you'd want to do.

Deiussum
06-19-2002, 04:58 AM
Ok, I admit maybe there's some fullscreen limitation on refresh rate. I don't write too many fullscreen demos.

But! OpenGL itself doesn't setup fullscreen, so the limitation would really be with the ChangeDisplaySettings API function, not OpenGL itself. Those games that use OpenGL fullscreen most likely don't request any particular refresh rate so it defaults to a "safe" one. With D3D, setting up the fullscreen is handled for you underneath.

Also, I think I read once that EnumDisplaySettings isn't guaranteed to give you a display mode that will work with your monitor.

06-19-2002, 01:57 PM
Earlier versions of win9x did not allowed the refresh rate to be changed from a program. I think that can explain some things about older games made before XP. I have not heard anything about EnumDisplaySettings but it is of course possible to set a unsupported value.

MrShoe
06-19-2002, 03:25 PM
When is OpenGL 2.0 coming out anyway?? Anyone have an approximate date? or month, or something?

rpxmaster
06-19-2002, 05:03 PM
On 06-19-2002 06:58 AM, a frequent contributor named Deiussum made the following remark:
Also, I think I read once that EnumDisplaySettings isn't guaranteed to give you a display mode that will work with your monitor.

That is absolutely correct, Deiussum. Direct3D checks to see of your monitor supports the display mode your program requests before it makes the switch. OpenGL, on the other hand, juts assumes it does. Therefore, it's important to code this check in yourself.

Funny thing how functions sometimes return values that nobody uses, and they should. Take the last line out of ScottManDeath's code above and append the following:



// derived from NeHe code
if (ChangeDisplaySettings(&amp;dmScreenSettings, CDS_FULLSCREEN) != DISP_CHANGE_SUCCESSFUL) {
MessageBox(HWND_DESKTOP, "Mode switch failed.\nRunning in windowed mode.", "Error", MB_OK | MB_ICONEXCLAMATION);
}

...or something similar, and it'll prevent your program from going 1600x1200x32 on my monitor, which doesn't support it.

06-20-2002, 05:15 PM
What happens if you call ChangeDisplaySettings like that and dmScreenSettings has unsupported values?

From the ChangeDisplaySettings documentation at msdn:

Remarks

To ensure that the DEVMODE structure passed to ChangeDisplaySettings is valid and contains only values supported by the display driver, use the DEVMODE returned by the EnumDisplaySettings function.

The msdn documentation sucks but I found this about DEVMODE:
When you call the EnumDisplaySettings function, the dmDisplayFrequency member may return with the value 0 or 1. These values represent the display hardware's default refresh rate. This default rate is typically set by switches on a display card or computer motherboard, or by a configuration program that does not use display functions such as ChangeDisplaySettings.

I guess that means that 0 or 1 can not be used to represent the default refresh rate in calls to ChangeDisplaySettings? Is this really the same for all Windows versions? I belive that the msdn gdi documentation is not complete about those functions.
Here is a starting point if anybody wants to search http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/devcons_7gz7.as