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.
 
GIJoe

March 21, 2005, 06:35 PM

Is this a project that can be downloaded, or something homegrown? I'm interested in playing with it.. :-)

 
[-WD40-]

March 21, 2005, 08:17 PM

Most of my work will be demo and testing. I will most probably be using Direct3D, while keeping tabs on OpenGL 2.0.


As another person suggested, I would choose DirectX for one main reason...RENDER TARGETS! They are a hell lot easier to create/play with than with OpenGL. And about the cross-platform argument...OpenGL is NOT entirely cross-platform...again...see the Render Target hell.

I can't wait to see the EXT_framebuffer_object becoming a reality, but then, considering how slow the ARB is I don't expect much from it. OpenGL 2.0 is a joke, it doesn't exists, it's not the 2.0 it should have been. It's OpenGL 1.6 really.

Anyhow ;) I seriously think DirectX is more easier and straightforward to use, especially when it comes to render targets and how they work.

 
KreK

March 23, 2005, 12:55 AM

There is no such thing as EXT fbo. ARB fbo is finalized (after having more than 100 revisions). Don't confuse ARB with graphics vendors, ARB cannot implement anything, it can only bring down specs. The newest NV drivers already have FBO functionality, as for ATI...

The reason for naming it 2.0 instead of 1.6 is because its main emphasis is on programmabile pipeline through GLSL instead of fixed function pipeline which was a primary method of programming for 1.x versions. It was therefore decided that no 1.x version should ever require mandatory GLSL support. Now you can argue if the switch from fixed function to programmabile is enough to justify major revision but D3D had major revisions for even less.

 
Reedbeta

March 23, 2005, 01:00 AM

Well, if you're going to be nitpicky, yes, there is an EXT_framebuffer_object (http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.txt). The ARB extension you are referring to is ARB_pixel_buffer_object (http://oss.sgi.com/projects/ogl-sample/registry/ARB/pixel_buffer_object.txt), which seems to offer roughly similiar functionality but has a completely different interface.

 
Scali

March 23, 2005, 02:47 AM

And all this confusion alone over something as horribly basic as render-to-texture is reason enough to avoid OpenGL :)

 
Chad Austin

March 23, 2005, 06:03 AM

Eh, I just copy the screen to a texture after rendering. Plenty fast for whatever I've needed render-to-texture for. (I understand there's a library that abstracts all the different ways you can do it: copy-to-tex, pbuffers, EXT_fbo) When EXT_fbo is finally available, we won't have to deal with it anymore. :P I understand the reason EXT_fbo took so long was because the ARB was actually trying to design something (super/uberbuffers, remember them?? from SIGGRAPH two years ago??) that was simply too complicated for the hardware. So they pared them down, called them "framebuffer objects" and added the necessary future compatibility pieces so render-to-vertex-array can happen in the future. And besides! Nobody was stopping the vendors from at least making their own render-target APIs...

You know, I'm actually quite surprised at the number of people who highly recommend DX9. (Not saying that's bad, just unexpected.) Things have really changed lately. Any guesses as to why this is so? Nice render targets is one reason... D3DX too?

To me, OpenGL has always been ahead, hands-down, primarily for two reasons:

1) MUCH lower batch cost. You can usually drop support OpenGL into fill-limited 2D apps and get great performance, even with immediate mode. Try the same in Direct3D and you'll be batch and state change limited in no time. I'm talking two orders of magnitude difference.

2) Other platforms. If your teams are anything like mine, all your artists are much happier using Maya on their Macs. They also want the rendering tools to work on Mac. And if you've ever played in the VR space, you've noticed Linux is pretty much what you get. Microsoft won't go away any time soon, but even if the Mac and Linux markets keep growing at the rate they are, it seems inevitable that games will need OpenGL support. And if what people are saying about the cost of switching is true, you may as well start with the one designed for compatibility and the future. :)

My $0.02,
Chad

p.s. D3DX is a very compelling advantage of D3D over GL. I think there is certainly room for a solid, open source C++ library or two that sit on top of OpenGL and provide the things we all need. Frankly, I can't believe nobody has tried to make even a simple vector math library for everyone. [That's not entirely true. GMTL kind of was intended for that, but isn't managed well enough to satisfy most people's needs.] But aren't we all tired of reinventing that particular wheel?? If several libraries standardized on one way to do basic linear algebra, imagine the effort saved writing adapters! (If you've ever mixed VRJuggler, OpenSG, Cal3D, and whatever other libraries that provide their own math classes, you know what I mean.)

 
gjaegy

March 23, 2005, 06:49 AM

anyway directx is better, isn't it lennox ;-)

 
Scali

March 23, 2005, 11:47 AM

Personally I mainly use D3DX as a glorified math lib. I don't use the mesh features and such. I use the shader assembler/compiler ofcourse, and also the texture loading functions.
But as you see, I didn't list it as one of the reasons why I prefer D3D, so at least to me, it's not that important, apparently.

As for batch costs... I'm not sure what kind of scenes you render, but in my case D3D and OGL don't make much of a difference. I wrote a visualization routine for hydraulic manifolds, where all drillholes were drawn with separate cylinder and cone objects. Even though I used indexed vertexarrays in OGL, it got very slow with only a few hundred objects. So my experience is not that it's all that much better than D3D. I haven't done any actual comparisons between D3D and OGL in that situation, but it was obvious that the OGL code required some optimization and reduction of calling overhead aswell (funny enough I tested on both a Radeon 9600Pro and a GeForce 6800, and they both got about the same framerates... So it wasn't ATi's allegedly bad OGL drivers that caused the bad performance, as I initially suspected).

Oh, and if you want Direct3D on Mac, visit www.macdx.com :)

 
KreK

March 23, 2005, 04:32 PM

You are correct. My mistake. I apologize.

"Despite being controlled by the ARB WG, this is not an officially approved ARB extension at this time, thus the "EXT" tag."

 
theAntiELVIS

March 24, 2005, 12:31 AM

Yes, DX changes a lot, but it's not as bad now as in the early days. The change from 7 to 8 was severe, but since then it's been incremental. It only takes minutes to port a v. 8 app to v. 9, and 8 was introduced, what, almost 5 years ago now?

Personally I think MS has made a mistake in the way it changes version numbers. Version 9 was more rightly v. 8.3 or something. They are too willing to tack-on a new number when the underlying core stays much the same.

 
Scoot

March 24, 2005, 01:23 PM

Would you agree that you can only truly optimise an application for one or other API?

Wrapping every API call is surely going to have a detrimental effect (however slight) on said performance.

[S]

 
Chad Austin

March 24, 2005, 02:46 PM

Truly optimize what? If you're willing to trade a 0.001% performance hit for code that's less able to migrate, then go ahead. I'd argue that it's much smarter to optimize for codebase longevity, clarity, and flexibility.

 
Scali

March 24, 2005, 03:01 PM

I agree. If you want a functional wrapper (one that actually works on more than one API, rather than an abstraction which can not be implemented on any other API than the one you are using), you automatically get the problem of the lowest common denominator.

Another problem can be that different APIs support the same functionality, but expose it in such a different way, that you have to abstract it at a higher level, which means you give up the possibility of optimizing it at the low level.

To be honest, I have never seen an engine that supports more than one API, while at the same time giving the same kind of performance and image quality as a 'pure' engine only targeting a single API. In fact, I've never seen an engine that supports more than one API, and reaches the same kind of performance and quality levels on the same machine using the different APIs.
In which case I'd say it's wasted effort to support multiple APIs... Just pick the best one for your engine, and support that to the best of its abilities. This is what I do anyway. I write separate engines for D3D, OpenGL and software rendering... At the higher level they all have a very similar interface, but at the low level they are very distinct. I could probably make the highlevel code (load object X, animate Y, turn on light Z, etc) actually work on more than one API... but the lowlevel code (like setting up vertexbuffers and shaders) have to be custom-written for each API. I don't think there's anything to gain by having an engine that can work with vertexbuffers at a lowlevel in an API-dependent way. It would just make the code suboptimal (having to convert vertexformats on-the-fly and nasty things like that).

 
Scali

March 24, 2005, 03:07 PM

I'd argue that it's much smarter to optimize for codebase longevity, clarity, and flexibility.


That's pretty much impossible with Direct3D anyway. You will already know that your DX9 code won't work as-is in the next Direct3D, which is not that far away. I consider all that code as disposable. I just write custom routines for that sort of stuff, and modify them to work with the next API.
I wouldn't really want to have code for ancient Direct3D in my current engine anyway. It's bad enough that my engine still supports fixedfunction... I will drop support for that soon, when I find it acceptable to demand shader support from the users. So there's no point in bothering for longevity there.

I concentrate on longevity with things that are more generic, like importers/exporters for geometry data, and various processing routines. That part will also be mostly API-independent. I use my own internal format, which is more convenient than the API-format... Then I have a 'disposable' routine that 'compiles' it into an optimal Direct3D vertexbuffer/indexbuffer format. I simply rewrite that for a new Direct3D or other API.

 
Scoot

March 24, 2005, 06:10 PM

To answer your rhetoric: yes. I would indeed trade *any* speed increase for lack of migrational ability. It all adds up.

We live in a time of slow hardware - things have taken a turn for the better recently but we are far from the generation where even commercial games engines are fast enough for the spread of hardware on which they are *expected* to function in a playable way without serious short-cuts and optimisation.

Example:
Doom III. Very nice. Did not run acceptably on a ti4600, which was not a cheap card when it arrived on the market. But then Id don't really have to worry about lack of sales volume, unlike 99% of developers and their publishers.

Developers: pick your spread of platforms. PC to Xbox is DX, Nintendo DS and similar handhelds/PDAs: dont even bother porting anyway requires a total rewrite and content reworking. To be honest the PS2/gamecube have so many annoying hardware-specific pecadillos that you'll *usually* end up rewriting most of your code anyway (most devs employ seperate experienced 3rd party teams to port these) and linux-runners and macs are not worth the bother. Purely in the commercial sense of course. If you are a garage/bedroom hobbyist then these arent issues to concern you anyway.

[S]

 
Chad Austin

March 24, 2005, 10:19 PM

I'm not sure you understand the nature of optimization. That virtual function call in your renderer? (The part you abstract.) It's going to be a tiny FRACTION of a percent of the amount of time it takes for the GPU to actually do the rendering.

It's silly to optimize on that level.

 
Scali

March 25, 2005, 01:38 AM

He never suggested anything like optimizing virtual calls. And he does make a valid point about Doom3, it really runs quite horribly on anything but the latest generation of hardware.

Then again, on the other hand there is Half-Life 2, which allows you to play the game very well on a wide variety of hardware.

However, Doom3's engine is not the kind of abstract multi-API engine that was being discussed earlier, as far as I know. And I don't really think you can say that the code wasn't optimized properly... The people at ID have a big reputation there, I suppose.
I think it's more a case of being overambitious, or perhaps having architected the engine wrongly (and perhaps having picked the wrong API, but that's another story)... in this I mean the use of stencil shadows everywhere. Half-Life 2 on the other hand has various rendering techniques, and picks the most suitable one for the target hardware. With Doom3 it's either shadows or no shadows... and let's face it... Doom3 is nothing without its shadows.

 
glWizardry

April 04, 2005, 09:33 PM


Gerald Knizia (cgk) wrote: 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.


That's utter nonsense. With a good design it is almost plug and play between them. Yes, it's alot of typing work for each one, but it is not difficult at all to do this. You get a lot of benefit from having both. Sometimes drivers for one card are good for one and not the other. Meaning, your user can switch the API type and fix the problem.

D3D has better documentation. OpenGL is generally more flexible and exposes the hardware more directly (from manufacturer to manufacturer). D3D is more uniform. OpenGL is diverse.

OpenGL (IMHO) is the better choice to learn. It requires more skill and understanding to develop a graphics application with it. But you gain valuable experience from this. D3D is not simpler than OpenGL. You still have to check capabilities, and have different paths for different capabilities. It is fundamentally no different then OpenGL in this respect.

As for GPU shaders. Bah. What a stupidity this whole issue has been. A zillion languages and interfaces. It is easily solved by investing a little time to develop your own tools for this, which can backend to whatever system you are using. It is work, yes, but the result is you have 1 interface to all hardware. If you do not want to actually write something like this, there are tools available like sh and Stanford shaders you can use. Generally, I say avoid all high level shading languages.

Why? Because they are fundamentally primitive at this point in time. The current generation of hardware do not scale well to high level languages at all. If you look at GLSL or HLSL program and realize the assembler generated for this you realize how terribly inefficient they are. And I doubt you will anytime soon see good compilers. Instead, they will just make the hardware bigger and faster so whatever is lost in quality is made up for in brute force approach.



 
Qndrez

April 04, 2005, 10:40 PM

I agree, the Cg compilers are abismal. nVidia needs to bring some compiler people in house.

-Andrew

 
Corre

April 05, 2005, 04:58 AM

Direct3D 9

 
kbray

April 05, 2005, 05:15 PM

Okay, I usually don't do this sort of thing, but I find this thread pretty appalling. I'm not trying to offend anyone here, but rather trying to point out some shortcomings in arguments, as well as a poor thought process towards tool selection.

There are a HUGE number of posts on this thread, and very few good arguements. First off, no one even defined what makes a good graphics API. How can you answer that as a question if no one even asks it? Second, there is a very high amount of misinformation.

What makes a good graphics API?

1.) Functionality
2.) Ease of use
3.) Performance
4.) Portability
5.) Backward compatibility

Each of these has a different importance based on your needs (for instance, if you're writing software that you know will be ported, then portability is very imporant).

Both Direct3D and OpenGL match up on functionality. They can each do pretty much the same things... there are some slight discrepancies, but most very minor.

Both Direct3D and OpenGL are easy to use... this largely depends on your programming style and philosophies. This will most likely not make or break your efforts.

Both APIs perform efficiently. Direct3D does have more CPU overhead than OpenGL, however, that can be fought by batching (really, you should do this with both; the fastest way to do something is to simply not do it). Both have the same performance characteristics when rendering, simply because that is dependent on the graphics card.

OpenGL is portable, but Direct3D is not. There are some open source efforts to create a Direct3D compatible OpenGL wrapper, however, this isn't as efficient as just going with OpenGL. You will also be rewriting parts of your engine that use calls that are not supported by the wrapper.

OpenGL's API does not change. Direct3D's API changes with every major revision. Direct3D's paradigm has the disadvantage here, simply because if you want to support a new feature that is not supported in the version of D3D that your engine was written against, then you'll have to port to the new version of D3D. However, D3D can clean up their API and remove features old, redundant entry points that are no longer needed. OpenGL will keep those features around, which is good for old code because it will still run, however, it adds to the size of the API making it more difficult to learn (for instance, which call is better? Example: glDrawArrays, glDrawRangeArrays).


Now, as far comments like:
"If you're just doing windows development, use D3D!"

This is just silly. Why use D3D? Simply because your application is windows only? What advantage to you get from this?

Also, comments like OpenGL is slower because Doom3 performs poorly on a GeForce4 are extremely misleading and just downright wrong. First off, if something performs well on one card and poorly on another, that doesn't mean the API is magically slower in that case. It means your application is stalled waiting on rendering to finish; ie, GPU bound. If Doom3 was written against D3D, you'd see the exact same problem.

Also, statements like "If it's good enough for Carmack, it's good enough for me!" are absurd. This is a logical fallacy! Just because someone (you percieve as better than you) does something one way doesn't mean they were right to do it that way! This attitude pisses me off: because someone better than me does it, it must be right! Wrong.

Sorry for the rant, and I don't mean to offend. Just be aware of your thinking. Problem solving is pretty straightforward. It's not a magical thing that the mind does unconsciously... it's a process:

1.) Define your problem
2.) Observe facts
3.) Find patterns
4.) Create multiple hypotheses.
5.) Try to prove your hypotheses wrong.
6.) When you're left with one hypothesis that you are having a hard time proving wrong, then test it.

Once again, I don't mean to offend. I know this is pretty harsh in places, but I believe sugar coating things just waters down the point being made.

Kevin

 
kbray

April 05, 2005, 05:17 PM

Sorry for the double post, but I'd prefer this to be top level.

Okay, I usually don't do this sort of thing, but I find this thread pretty appalling. I'm not trying to offend anyone here, but rather trying to point out some shortcomings in arguments, as well as a poor thought process towards tool selection.

There are a HUGE number of posts on this thread, and very few good arguements. First off, no one even defined what makes a good graphics API. How can you answer that as a question if no one even asks it? Second, there is a very high amount of misinformation.

What makes a good graphics API?

1.) Functionality
2.) Ease of use
3.) Performance
4.) Portability
5.) Backward compatibility

Each of these has a different importance based on your needs (for instance, if you're writing software that you know will be ported, then portability is very imporant).

Both Direct3D and OpenGL match up on functionality. They can each do pretty much the same things... there are some slight discrepancies, but most very minor.

Both Direct3D and OpenGL are easy to use... this largely depends on your programming style and philosophies. This will most likely not make or break your efforts.

Both APIs perform efficiently. Direct3D does have more CPU overhead than OpenGL, however, that can be fought by batching (really, you should do this with both; the fastest way to do something is to simply not do it). Both have the same performance characteristics when rendering, simply because that is dependent on the graphics card.

OpenGL is portable, but Direct3D is not. There are some open source efforts to create a Direct3D compatible OpenGL wrapper, however, this isn't as efficient as just going with OpenGL. You will also be rewriting parts of your engine that use calls that are not supported by the wrapper.

OpenGL's API does not change. Direct3D's API changes with every major revision. Direct3D's paradigm has the disadvantage here, simply because if you want to support a new feature that is not supported in the version of D3D that your engine was written against, then you'll have to port to the new version of D3D. However, D3D can clean up their API and remove features old, redundant entry points that are no longer needed. OpenGL will keep those features around, which is good for old code because it will still run, however, it adds to the size of the API making it more difficult to learn (for instance, which call is better? Example: glDrawArrays, glDrawRangeArrays).


Now, as far comments like:
"If you're just doing windows development, use D3D!"

This is just silly. Why use D3D? Simply because your application is windows only? What advantage to you get from this?

Also, comments like OpenGL is slower because Doom3 performs poorly on a GeForce4 are extremely misleading and just downright wrong. First off, if something performs well on one card and poorly on another, that doesn't mean the API is magically slower in that case. It means your application is stalled waiting on rendering to finish; ie, GPU bound. If Doom3 was written against D3D, you'd see the exact same problem.

Also, statements like "If it's good enough for Carmack, it's good enough for me!" are absurd. This is a logical fallacy! Just because someone (you percieve as better than you) does something one way doesn't mean they were right to do it that way! This attitude pisses me off: because someone better than me does it, it must be right! Wrong.

Sorry for the rant, and I don't mean to offend. Just be aware of your thinking. Problem solving is pretty straightforward. It's not a magical thing that the mind does unconsciously... it's a process:

1.) Define your problem
2.) Observe facts
3.) Find patterns
4.) Create multiple hypotheses.
5.) Try to prove your hypotheses wrong.
6.) When you're left with one hypothesis that you are having a hard time proving wrong, then test it.

Once again, I don't mean to offend. I know this is pretty harsh in places, but I believe sugar coating things just waters down the point being made.

Kevin

 
glWizardry

April 07, 2005, 01:12 AM



kbray wrote: Sorry for the double post, but I'd prefer this to be top level. Okay, I usually don't do this sort of thing, but I find this thread pretty appalling. I'm not trying to offend anyone here, but rather trying to point out some shortcomings in arguments, as well as a poor thought process towards tool selection. There are a HUGE number of posts on this thread, and very few good arguements. First off, no one even defined what makes a good graphics API. How can you answer that as a question if no one even asks it? Second, there is a very high amount of misinformation. What makes a good graphics API? 1.) Functionality 2.) Ease of use 3.) Performance 4.) Portability 5.) Backward compatibility Each of these has a different importance based on your needs (for instance, if you're writing software that you know will be ported, then portability is very imporant). Both Direct3D and OpenGL match up on functionality. They can each do pretty much the same things... there are some slight discrepancies, but most very minor. Both Direct3D and OpenGL are easy to use... this largely depends on your programming style and philosophies. This will most likely not make or break your efforts. Both APIs perform efficiently. Direct3D does have more CPU overhead than OpenGL, however, that can be fought by batching (really, you should do this with both; the fastest way to do something is to simply not do it). Both have the same performance characteristics when rendering, simply because that is dependent on the graphics card. OpenGL is portable, but Direct3D is not. There are some open source efforts to create a Direct3D compatible OpenGL wrapper, however, this isn't as efficient as just going with OpenGL. You will also be rewriting parts of your engine that use calls that are not supported by the wrapper. OpenGL's API does not change. Direct3D's API changes with every major revision. Direct3D's paradigm has the disadvantage here, simply because if you want to support a new feature that is not supported in the version of D3D that your engine was written against, then you'll have to port to the new version of D3D. However, D3D can clean up their API and remove features old, redundant entry points that are no longer needed. OpenGL will keep those features around, which is good for old code because it will still run, however, it adds to the size of the API making it more difficult to learn (for instance, which call is better? Example: glDrawArrays, glDrawRangeArrays). Now, as far comments like: "If you're just doing windows development, use D3D!" This is just silly. Why use D3D? Simply because your application is windows only? What advantage to you get from this? Also, comments like OpenGL is slower because Doom3 performs poorly on a GeForce4 are extremely misleading and just downright wrong. First off, if something performs well on one card and poorly on another, that doesn't mean the API is magically slower in that case. It means your application is stalled waiting on rendering to finish; ie, GPU bound. If Doom3 was written against D3D, you'd see the exact same problem. Also, statements like "If it's good enough for Carmack, it's good enough for me!" are absurd. This is a logical fallacy! Just because someone (you percieve as better than you) does something one way doesn't mean they were right to do it that way! This attitude pisses me off: because someone better than me does it, it must be right! Wrong. Sorry for the rant, and I don't mean to offend. Just be aware of your thinking. Problem solving is pretty straightforward. It's not a magical thing that the mind does unconsciously... it's a process: 1.) Define your problem 2.) Observe facts 3.) Find patterns 4.) Create multiple hypotheses. 5.) Try to prove your hypotheses wrong. 6.) When you're left with one hypothesis that you are having a hard time proving wrong, then test it. Once again, I don't mean to offend. I know this is pretty harsh in places, but I believe sugar coating things just waters down the point being made. Kevin


You spiel was amazing and full of depth. But you did not help answer the question in any way whatsoever.

Look, this guy has little experience, he can only define his problem as the fact he does not know which graphics API to choose. Anything beyond that at his point is really not possible as he has NO experience to draw upon to interpret the facts to the problem.

This is why I mentioned to do both. I do not think it is harder at all. And, you will come out much stronger than just going down the path of doing one API. There are a number of issues central to serious graphics design you can learn from implementing a render API independent application.

If he just wants to piddle around, than by all means choose Direct3D. Not because it is better or worse, but simply because it's documentation is great, it has numerous support tools, and it is much easier to break into than OpenGL.


 
kbray

April 07, 2005, 09:34 PM

I disagree with you about not helping answer his question. I intentionally tried to avoid that case, which is why I provided the following:

> What makes a good graphics API?
>
> 1.) Functionality
> 2.) Ease of use
> 3.) Performance
> 4.) Portability
> 5.) Backward compatibility
>
> Each of these has a different importance based on your needs (for instance,
> if you're writing software that you know will be ported, then portability is
> very imporant).
>
> Both Direct3D and OpenGL match up on functionality. They can each do pretty
> much the same things... there are some slight discrepancies, but most very
> minor.
>
> Both Direct3D and OpenGL are easy to use... this largely depends on your
> programming style and philosophies. This will most likely not make or break
> your efforts.
>
> Both APIs perform efficiently. Direct3D does have more CPU overhead than
> OpenGL, however, that can be fought by batching (really, you should do this
> with both; the fastest way to do something is to simply not do it). Both have
> the same performance characteristics when rendering, simply because that is
> dependent on the graphics card.
>
> OpenGL is portable, but Direct3D is not. There are some open source efforts
> to create a Direct3D compatible OpenGL wrapper, however, this isn't as
> efficient as just going with OpenGL. You will also be rewriting parts of your
> engine that use calls that are not supported by the wrapper.
>
> OpenGL's API does not change. Direct3D's API changes with every major
> revision. Direct3D's paradigm has the disadvantage here, simply because if
> you want to support a new feature that is not supported in the version of D3D
> that your engine was written against, then you'll have to port to the new
> version of D3D. However, D3D can clean up their API and remove features old,
> redundant entry points that are no longer needed. OpenGL will keep those
> features around, which is good for old code because it will still run,
> however, it adds to the size of the API making it more difficult to learn
> (for instance, which call is better? Example: glDrawArrays,
> glDrawRangeArrays).

I intentionally avoided coming to a conclusion because I don't want to bias his decision. Instead, I attempted to present him with facts that he could then use to make his decision.

Also, I would like to state that I was not criticizing him or his post for anything. Instead, I was criticizing the answers he recieved. Sorry for not being clearer about that.

As far as making an engine API independent, that's not a bad approach. I personally don't like that approach on non-console titles because I feel it just adds to development/maintainance costs without providing any actual functionality to increase sale value. This would, however, be a good approach for say PC, Mac and XBox development. It would likely save time in that case as well. As for learning, it may be a good approach, but I think it would be a better thing for someone who already has intimate knowledge of both APIs.

As far as documentation goes, the entire OpenGL spec can be downloaded at http://www.opengl.org and all of the extensions can be found at http://oss.sgi.com/projects/ogl-sample/registry/ . I've personally found the documentation for OpenGL to be more thorough where as I've found areas where the Direct3D documentation tends to be unclear. For instance, in ID3DXEffect::SetValue(); if you're setting a boolean, the size is 4 bytes and is treated like an integer. That behavior is not defined anywhere in the documentation (however, this exact case is covered by the OpenGL shader language spec).

As far as Direct3D being easier to break in to, I'd like to hear more of your opinion about that. There is a learning curve to both, but any beginner's book for either API should do the trick. I personally feel they're both just as easy to learn.

Kevin

 
Scali

April 08, 2005, 06:02 AM

Why do I taste a bias to OpenGL even though you claim you don't want to actually answer the question?

For example, the portability of OpenGL is oversimplified... None of the potential work in porting is discussed (eg different window-handling code, different ways to access extensions... vendor-specific extensions may be a huge problem when porting... etc).
It's not just write-once, compile-anywhere.

And pointing out the boolean thing in the documentation is well... silly. Sure if you look hard enough, you can find something funny anywhere.

You also fail to point out that OpenGL has some severe pitfalls on PC hardware, because some of the core functionality is not supported by consumer hardware, which forces the driver to go into software emulation mode... These problems can be as simple as trying to read or modify a z-buffer, or setting the wrong texture address wrapping mode.
I don't know of any docs that actually point out those problems. The core is just assumed to be completely supported in the OpenGL docs themselves. Which is not the case.

 
kbray

April 08, 2005, 11:32 AM

The core OpenGL code is "write once, run anywhere", however, the code to initialize OpenGL is not. Also, there are byte ordering issues on different chips, but that would be a problem for anything portable. Note that if you use Direct3D, you're pretty much going to be rewriting the renderer in OpenGL on non-Windows platforms anyways assuming you're not doing something basic enough that you can use an open source wrapper (which pretty much limits you to fixed function afaik).

As far as pointing out the boolean issue in documentation, its a recent example that I came across. I've written 4 engines, some professionally, some on the side. 2 have been D3D, 2 have been OpenGL. I have found that subtle problems like this pop up in the Direct3D documentation a lot more than in the OpenGL documentation. Usually, if I have problems with OpenGL's documentation, its with vendor specific extensions, which I don't use that often to begin with, and in most cases, should be avoided unless necessary (and even then, its rare... few enough to count on one hand).

As far as OpenGL core functionality being emulated in software... this used to be a problem, but on modern hardware, its really not. In both of my OpenGL engines, I never once hit a case where I was accidentally using features emulated in software. There are also a lot of documents out there which aim to help people avoid that case as well. Believe me, it's *rare* these days (and has been for the last two years).

As far as being biased toward OpenGL, I'll admit it: I probably am. I've done enough work to be able to compare the two side-by-side, and I've come the conclusion that OpenGL is a superior API. Given my listing of important API features and my side-by-side comparison, is there any wonder why I would be biased toward OpenGL? I listed the attributes of each API that I've used to make my decisions in the past. If I'm missing something, then by all means, feel free to add it.

In retrospect, I'd like to add something to the "ease of use" section. Offscreen rendering in OpenGL has traditionally been a royal pain. Simply put, Pbuffers suck. They make managing render-states just short of a nightmare. In the past, I'd recommend using D3D if you're doing something render-target intensive. However, this is no longer a problem due to a new render-target extension. It definately makes offscreen rendering a lot easier to do. (note that I left this out because the extension is already available in beta drivers, and this shouldn't be an issue for someone just starting development)

I'd also like to add something else to my ease of use section. There is another drawback to using OpenGL which doesn't have to do with OpenGL itself, but rather ATI's implementation of it. ATI implementations don't return errors where they should. NVidia drivers, however, don't have this problem. If you develop on ATI, as soon as you try to run on different hardware, there is a 99.9% chance that you'll find a ton of bugs in your code where things were quietly failing. In short, if you use OpenGL, develop using NVidia hardware and you shouldn't have any problems going to ATI hardware (otherwise, you'll have to be extremely careful). Note that Direct3D does not have this problem due to WHQL tests. If you have no choice but to develop on an ATI card, you might even be better off going with Direct3D just to avoid that mess.

One arguement for OpenGL that falls under the functionality catagory is that there are features of some hardware that Direct3D does not expose. For instance, floating point textures on GeForceFX 5xxx series hardware. This is because the hardware expects denormalized texture coordinates, which isn't in the Direct3D standard. While this would require an addition code path for places that use floating point textures, it's at least available to use under OpenGL. If you want to go the Direct3D route, and just not support them on GeForceFX 5xxx, then thats fine also and requires no additional work.

Here was a more in-depth comparison of features and caveats, so I hope this puts to rest the idea that I'm attempting to bias the reader. I'm simply trying to present the facts that I know to enable others to make the decision they see as the correct one. If I'm missing information or leaving something important out, I'd definately like to know about it.

 
criznach

April 08, 2005, 12:37 PM

The suggestion to support both is crazy. This guy is a beginner and doesn't know enough about either platform to choose. To write a decent wrapper you'd have to know both APIs fairly well and have used them both. When learning 3d programming, I was more concerned with the general concepts than the API. Since then I've learned a fair bit about both OpenGL and Direct3D.

My recommendation would be to look at the docs for an hour (or even a day) each. Decide which suits your style. It's been stated here several times that you can do more or less the same things with both APIs.

 
Scali

April 08, 2005, 01:20 PM

You are now making it your personal thing... "I don't use this...", "I have never had a problem with that..."...
That is fine, but I'm sure we can find people who can promote Direct3D in the same way...
But not everyone may use Direct3D or OpenGL exactly like you, so they may run into problems that you have never had.
Which is a bit of a disappointment after that long first post of yours, explaining the whole decision methodology :)

 
kbray

April 11, 2005, 09:41 AM

I don't understand why you say I'm 'making it my personal thing'. I simply pointed out my beliefs about supporting both APIs, and I'm essentially pointing out that I don't care to argue further over that point (hence the "I have never had a problem with that"). I think you perhaps misunderstood what my point was. Anyways, would you care to elaborate further?

 
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.