Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / 3D Theory & Graphics / OpenGL 2.0 or Direct3D 9 Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
hishadow

March 14, 2005, 11:13 AM

First off, I've done programming in both API some year and a half ago. But I have not been able to find much spare time in my study. But since I'm gearing toward computer graphics, I would like to concentrate more on one API. I originally learned OpenGL 1.3 and then I jumped to Direct3D 8&9.

Now I want to brush up on my old knowledge and learn some new skills, especially concerning shaders. I've been meaning to return to OpenGL 2.0, but I'm somewhat hesitating. Also, looking at this forum, there seems to be very little technical discussions surrounding the new OpenGL (maybe a bit early?). I still got my OpenGL Shading Language book which I did some testing with in OpenGL 1.5. But driver support then was a bit sketch. The shader language seemed pretty solid though and well documented.

Any views on where I should turn?

 
Volker Schoenefeld

March 14, 2005, 11:29 AM

My university is using OpenGL exclusively (linux machines only), and I think that does as well apply to a lot of (if not almost all) other universities. If you plan to focus on computer graphics later in your advanced study period, I'd rather stick to OpenGL.

If you are only doing this for yourself (and possibly for a job) I think DirectX is the way to go (and whatever the followup APIs are called today). It's a lot faster and better maintained, compared to the lousy ARB work. Also driver support is supposed to be better at least on ATI cards. Oh and I think DirectX is also simpler to use initially, and offers a vast toolkit (from what I've heard and seen :).

If you want platform independence OpenGL is the way to go. And if you ever think about using *nix, you should also stick to OpenGL. I think you should just look at both (which you already did :) and decide yourself, what you like more.

 
cppkid

March 14, 2005, 03:02 PM

I use OpenGL (1.5 currently - 2.0 drivers are beta) and the advantages are numerous:

- Compatiblity with Windows/Mac/Linux
- Basis for Playstation 3 graphics API (it will use OpenGL ES)
- Compatible with Java, Python, C, C++
- If it's good enough for Carmack, it's good enough for me

The only major disadvantage is poor ATI driver support, however this has improved since Doom 3 was released. The API's are fundermentally the same - they are after all abstracting the same hardware.

 
Axel

March 14, 2005, 03:20 PM

My advice to this discussed-to-death-topic is that you should simply support both through different backend DLLs. It's good coding style to abstract that anyway.

 
theAntiELVIS

March 14, 2005, 03:22 PM

If you want to get a job, work with both. Then you're covered.

If you want to do hobby stuff, and work only in Windows, DirectX is the way to go.

If you are working toward some kind of independent commercial project, then you just need to decide what your market is, and since the vast majority of machines run Windows, DirectX is again probably the way to go, unless you specifically want to hit the Linux/Mac market as well.

Be aware that DirectX is about to undergo some BIG changes as "Longhorn" approaches. MS has already dumped some parts of the API - DirectPlay networking is to be replaced by a more general Windows-based API, for example. And the DirectShow media API is also apparently headed for replacement with some more gneral media layer in Windows. But I imagine the graphics API will retain a lot of the current DX features, although from the way the SDK has been changed with DirectX 9c, it appears the FX scripting facility will play a more prominent role (just a guess).

 
Chad Austin

March 14, 2005, 03:41 PM

I see a lot of "DirectX and OpenGL are basically the same. But if you don't care about other platforms, use DirectX." Why in particular? (Easier render targets is the biggest reason I can think of. The next generation of drivers should have framebuffer_object support all the way back to GF1 though.)

An interesting question came up during the OpenGL tutorial at GDC. The moderator asked the panel "Is OpenGL still relevant today?" One of the answers was that the OpenGL extension mechanism that, while slower than the rate at which Microsoft changes DirectX, makes sure than the OpenGL core spec stays solid. If an extension goes through the vendor -> EXT -> ARB -> core process and stays alive, it's probably worth having in the long run. They also brought up the fact that you can take OpenGL apps from years ago and compile/run them unmodified on newer hardware. DirectX, on the other hand, changes all of the time, which requires that Microsoft ship DirectX interfaces all the way back to version 3.

Another interesting one: "Will OpenGL support instancing?" Answer: "We already have it, it's called immediate mode." Since batches in OpenGL are so much cheaper, you just use a VBO to draw an object, then use immediate mode to change the attributes/state you're updating at a lower rate, then use the VBO again to draw more objects.

Anyhow, I agree with the notion that if you design your rendering architecture in a general-ish way, it's pretty straightforward to support both OpenGL and DirectX.

 
Gerald Knizia (cgk)

March 14, 2005, 03:44 PM

My advice is to _NOT_ bother supporting both APIs. It would require a lot of work and get you exactly zero benefit. Choose DirectX or OpenGL and stick to that.

That said, I'd also recomment DirectX if you can live with the fact that this will prevent the use of your applications in Linux. The benefit of DirectX is that it is well documented, easy to use (especially concerning hardware compatibility across different vendors) and often redesigned and changed to work for the better, once MS, NVidia, ATI and the others actually know what the better is. There are nearly no ugly hacks in DX just for backward compatibility, which makes DX a really well-structured API.

 
Axel

March 14, 2005, 04:03 PM

My advice is to _NOT_ bother supporting both APIs. It would require a lot of work and get you exactly zero benefit. Choose DirectX or OpenGL and stick to that.

You can always define a interface that will work with both and start using only one. As I said you should abstract the low level things anyway.
Later if you need to support the other too it will be much easier.

 
Chad Austin

March 14, 2005, 04:23 PM

That said, I'd also recomment DirectX if you can live with the fact that this will prevent the use of your applications in Linux. The benefit of DirectX is that it is well documented, easy to use (especially concerning hardware compatibility across different vendors) and often redesigned and changed to work for the better, once MS, NVidia, ATI and the others actually know what the better is. There are nearly no ugly hacks in DX just for backward compatibility, which makes DX a really well-structured API.


OpenGL is well-documented too. The spec is pretty straightforward, MSDN has good OpenGL 1.1 docs, the red and orange books document OpenGL 1.4 and GLSL (respectively) very well.

If you stick with ARB extensions, you'll be very portable across cards too. It's no different than the CAPS in DX. And with the advent of glinfo, it's easy to see what functionality is available where.

Ugly hacks?

 
KreK

March 14, 2005, 04:32 PM

A lot of work? Have you ever done any porting between OpenGL and DirectX?

I recently had to convert a DirectX algorithm wich I was developing for the last 2 months(roughly), and it took me just 2 days to convert it to OpenGL. Algorithms stay the same, only function calls change.

The point is that DX and OpenGL are so similar to each other (fixed pipeline or shaders), the time spent porting between them is insignificant compared to time needed to design various algorithms.

I do agree, however, that if you platform of choice is Windows/X-Box, then you gain nothing for supporting OpenGL.

On the other hand, as they say for OpenGL: "From cell phones to supercomputers."

 
Marmakoide

March 14, 2005, 04:58 PM

OpenGL is mainly used because you can compile old applications (API stability), and works on nearly every stuffs with a GFX card. It used even for 2D works... And see Doom3 or Quake3.

Game players mainly use Windows, so for economic purposes, the GFX card drivers are probably designed with Direct3D in mind. So if your Windows application have a short life time (Like a demo), it's the best choice.

If you like OOP, you could design your game/demo/engine with a special low-level handling interface class for the gfx card command. An implementation of this class per API, and you could sleep. Not the hell to do.

 
Lennox

March 14, 2005, 06:23 PM

To answer your question, I agree with most others on the list. Abstract out your rendering if you can. I don't see how you can abstract out the shaders though unless you use something like CG. If your main focus is PC/X-Box stick with Direct3D. If you care about PDAs, cross plaformability or industry standard, stick with OpenGL. I figure MSFT will come up with a hardware accelerated solution for PDA's, but till then there's only OpenGL ES. D3D seems to be prevalent in the game world, but in the application world I still believe that OpenGL has the upperhand...but I have nothing to back that up with.

You'll run into more driver issues with OpenGL, but at least you can be sure that your code is portable and cleanly written (purely opinion based, so no argument plz). One of the most frequent driver issues we see is on new installs of Windows XP, OpenGL reference drivers get installed which are slow as slow can get.

Now thats over, I would like to state that for those claiming that the DirectX interface doesn't change, what vesion did they start with? I started out a little far back in the days, and I can honestly say that OpenGL hasn't change. If you just started with DX8, then you're not basing this on anything. I remember the days of DX5, those were some very very horrible days (probably even worse before that). All I gotta say is you better hope that DX10 or whatever they come up with isn't a completely brand new API that you must upgrade to the newest version of the OS in order to take advantage of (sounds like IE and Netscape all over again).

 
hishadow

March 14, 2005, 08:42 PM

Thanks for all the input. Looking at this discussion, you see my dilemma :) I have no cross platform consideration. Most of my work will be demo and testing. I will most probably be using Direct3D, while keeping tabs on OpenGL 2.0.

Anyway, the graphics API will be the least of my problems when working on my masters.

Edit:
At my university they have been pretty flexible on what software you can use. But seeing many of my graphics teachers attending the Richard Stallman lecture.. things might be changing :)

 
Vast

March 14, 2005, 09:51 PM

WOW, sry for being a tid-bit offtopic, but i am amazed how mature this forum is. I did not even want to view this post at first, but then i couldnt keep myself from doing that, and i am amazed! No flaming, no offense in regard to one another's statements. Guys, I am really proud of being part of this forum.

Thats all.
Sry for being offtopic. Just want everyone to know, and probably realize that ( dont want to be alone.. heh )

Tim

 
Gerald Knizia (cgk)

March 15, 2005, 02:46 AM

A lot of work? Have you ever done any porting between OpenGL and DirectX? I recently had to convert a DirectX algorithm wich I was developing for the last 2 months(roughly), and it took me just 2 days to convert it to OpenGL. Algorithms stay the same, only function calls change.

If it takes some days to port a application to another API, than I consider this "a lot of work" for a task that most probably won't give you any benefit.

You say you needed two days to port the implementation of one algorithm. Well, in your application you probably have a lot of gfx-card-specific algorithms and that "only takes a few days"-tasks tend to sum up very quickly. Also, you developed and tuned your algorithm yourself first. But most algorithms need not be developed before implementing them, because they are well-known to the community. And in this case you'd just double your work.

The point is that DX and OpenGL are so similar to each other (fixed pipeline or shaders), the time spent porting between them is insignificant compared to time needed to design various algorithms.

Right, the core-features can be translated roughly one-to-one. But then there are the more advanced and more subtle features you won't have access to if you don't stick to one of the APIs.
If choosing to support OpenGL for example, you should better not use the D3DX library -- as these contains a lot of features that are just not present in OpenGL or are accessed in a completely differnent way there. Sure, D3DXCreateTextureFromFileInMemory (with jpg and png support), the ID3DXFont stuff or the D3DX built in support for GUIs are not rocket science. But they come in handy and I would not want to implement them myself if I hadn't to -- it's not worth my time. If supporting both APIs and requiring any of that features, there would not really be any way around that however[1].

And there are bugs. Bugs in your code when implementing algorithms. Who has not already spent serveral hours debugging because he mixed up the meaning of some index in some API call somewhere deep in the code? You'd double that time too, and in OpenGL you don't have a debug-runtime that usually tells what is going wrong.

The next point is: Currently, with OGL 2.0, all hardware features are exposed rather clean by OpenGL. But this has not been the case in the last years and most probably we'll see the same vendor specific extension-mess of the last years again once some new years have passed.

On the other hand, as they say for OpenGL: "From cell phones to supercomputers."

Right. If you care about portability, you should definitaly support OpenGL. But than again, there would not be much point in supporting DirectX too.

[1]: I wonder if D3DXs radiance transfer calculation module will come to broad use in some time.

 
Axel

March 15, 2005, 06:29 AM

I don't see how you can abstract out the shaders though unless you use something like CG

I use an embedded meta shader language that's converted to GLSL or HLSL by the backend :)

 
Erik Faye-Lund

March 15, 2005, 10:06 AM

I use both, depending entirely on the project and who I work with. At work, I do all OpenGL (ES). At my spare time I prefer D3D9 if I get to choose. But it's really not that big of a deal. Both APIs are fairly good, both has advantages and disadvantages. And they're both improving by time. So my answer would be to consider the needs for your project.

 
Erik Faye-Lund

March 15, 2005, 10:09 AM

I wouldn't feel TOO sure that OpenGL apps will run on OpenGL ES 2.0 without either being written with care and knowledge of the (unfinished) spec or quite a bit of porting.

 
zed zeek

March 16, 2005, 12:15 PM

Game players mainly use Windows

actually most gamers play on consoles i think the ratio is about 85% to 15%.
the ps3 will be using opengl es.
the ps2 sells more games than the pc/xbox/gamecube combined.

 
Chad Austin

March 16, 2005, 12:20 PM

Really? What does it look like?

 
Axel

March 16, 2005, 12:49 PM

VertexShaderPositionInput in_position;
VertexShaderPositionOutput out_position;
ShaderVector position;

position["xy"] = in_position;
position["zw"] = ShaderValue(1.0f,1.0f);

out_position = position;

 
Chad Austin

March 16, 2005, 01:41 PM

Ah, so it's sort of a meta-language on top of C++?

 
Axel

March 16, 2005, 02:43 PM

Yes, I use this to dynamically generate shaders that the user can customize.

 
Scali

March 16, 2005, 05:40 PM

I have used both OGL and various versions of D3D... I prefer Direct3D myself, and I would advise that to others aswell, as long as portability is not an issue.
Some advantages are that it is more up-to-date and has better support from manufacturers, and has more tools/docs/etc available, because it is used by so many developers.

And I want to stress that they are NOT entirely equivalent... A while ago I had to develop an algorithm, for which I made the prototype in D3D, because I was more at home there. Then I had to convert it to OpenGL for the final product... And I ran into two nasty problems... First problem was that apparently it was (is?) not possible to create separate depth/stencilbuffers and swap buffers independently from the framebuffer. This was crucial to my algo, so I had to do a slow workaround via the CPU.
Second problem was that one PC in the office had a Matrox card, which apparently had no support for any kind of render-to-texture operations at all. Even though it could run the D3D version of the algo just fine.

 
hercule

March 17, 2005, 07:55 AM

Please don't say that directx is better than opengl, that's false like saying opengl is better than directX.
That's just 2 different API, answer different needs.

Opengl:
+ portability
+ support for the professional application.
low level API:
+ more room for optimisation
+ you can shoose other library, and even mix it with directx (directsound and directplay)
- more work for the same thing
+ The API don't move throw years.

directx:
+ support from the game industrie
+ support from Microsoft and his marketing team.
- That's microsoft, and even if it's almost free now, who knows what will happen in the futur?
high level API
+ lots of good utily, already optimise.
+ simplification of some call.
+ applications are developped faster.

+ the API give a none CG specific interface faster
- The API often change.

And there is a programming style. Some like directX, other prefer opengl.
None of this two API is better. Choose the one you like :)

Scali you make two mistake:
Opengl with extension is more uptdate than directX (more work to use them).
Your case for your algo is very particular, and you should have meet the same problem going from opengl to direxctX. It's more a matrox driver question, and everyone know how much matrox is good in 3D..

The quality of docs/tools is maybe better for Opengl, because the API don't change a lot. A tutorial wrote 10 years ago, is good now too :)


Sorry for my english, I'm French.


 
Scali

March 21, 2005, 12:38 PM

Please check your OpenGL zealotry at the door, rather than calling my experiences 'mistakes'.
And I never said D3D is better than OpenGL. Please read more carefully, especially if your English is not that good.

 
Lennox

March 21, 2005, 01:20 PM

Not arguing here, but I had the same issue but in reverse. We can't have a stencil buffer with D3D if we want to do readback of the Z-Buffer for an algorithm to compute intervisibility calculation. This was easy for OpenGL but hard for D3D for various reasons. The algorithm had to be reworked to not use the Z-Buffer at all. It all depends on what you're doing.

 
Scali

March 21, 2005, 04:03 PM

The truth is that you can't do it in OpenGL either, at least, not on regular consumer hardware. But since it is in the OpenGL API, the drivers have to implement a fallback.
As you will notice, reading back the zbuffer is horribly slow in OpenGL, because the driver has to convert the proprietary internal zbuffer format to the format that you requested via OpenGL.
If you need to do this, your algorithm is wrong. Apart from the fact that it is horribly slow, the problem is also that the reading and writing doesn't guarantee a 1:1 conversion.
It is often faster to generate a second copy of the zbuffer by simply rendering the same geometry again to a new zbuffer... or another trick is to render the z to the alphachannel of an ARGB texture, or a more suitable rendertarget.

Basically, if it can't be done in D3D, then it can't be done on most consumer hardware.
With OpenGL there is a far less direct link between the API and the hardware, which can be quite a pitfall when you want good performance.

 
Nils Pipenbrinck

March 21, 2005, 04:17 PM

Is it just me who thinks that the code that calls 3d-api makes up less than 5% of a project, that porting from one api to the other is a matter of few weeks and almost nil compared to the time it takes to actually finish something?

 
Scali

March 21, 2005, 04:28 PM

With the advent of shaders and all kinds of special features like render-to-texture, this is no longer true.
If you use dozens of shaders, you'll have to rewrite all of them, which could take quite a while (let's not get into CG, shall we...).
And if you use shading somewhat more complicated than just the built-in gouraud+texture stuff, you'll have to rewrite all those algos aswell (the setting up of texture filtering, wrapping modes, changing of rendertargets and whatever... unless you already spent a lot of time in the first place to wrap everything in a non-API-specific matter... and did that so well that it could actually be ported without (unforeseen) problems...).
And I believe we're talking about a strictly visual application here... so the whole project is the visualization.

So no, I don't agree, it's not trivial to swap from one API to the next... at least, not in every case. Only in the case where the visualization is very trivial.
I wonder how much of the code in eg Half-Life 2 is shader/D3D-related... probably a whole lot, since they used hundreds of shaders.
And since they used an existing library for physics, that part of the project is probably not too large either... I wouldn't be surprised if almost 50% of their code is related to graphics.

 
This thread contains 59 messages.
First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.