Original Post
Should a game engine support both OpenGL and DirectX? If it's 'better' to support them both, then why? OpenGL is cross platform, why not only use that one? Thanks in advance, Kees
🔒 Locked
Engine question
Advertisement
Quote:
Original post by Kees Waagmeester
OpenGL is cross platform, why not only use that one?
I can't speak for all people, but OGL is a pain to use compared to D3D when you start doing anything remotely serious.
As for supporting both OGL and D3D, it's something to keep in mind when desiging, maybe abstract your renderer, but it's not terribly important in this day and age. Hell, neither HL2 nor Doom 3 bothered.
Quote:
Original post by Promit
I can't speak for all people, but OGL is a pain to use compared to D3D when you start doing anything remotely serious.
why?
If you're designing your engine to be competitive with other free engines like OGRE, then *maybe* supporting both is a good idea...
Otherwise, IMO there's really no point in supporting both. Then the decision boils down to, cross platform or not? If cross platform, then OpenGL, else DirectX. Keep it simple :)
Otherwise, IMO there's really no point in supporting both. Then the decision boils down to, cross platform or not? If cross platform, then OpenGL, else DirectX. Keep it simple :)
OpenGL is available on platforms other than Windows; DirectX is not.
DirectX has better hardware compatibility among off-brand Windows hardware -- which has something like 20% of the market. If you want to run on hardware that's not from NVIDIA, ATI or Intel, you're likely better off with DirectX on Windows.
Thus, you need both if you want maximal coverage.
DirectX has better hardware compatibility among off-brand Windows hardware -- which has something like 20% of the market. If you want to run on hardware that's not from NVIDIA, ATI or Intel, you're likely better off with DirectX on Windows.
Thus, you need both if you want maximal coverage.
Quote:
Original post by _the_phantom_ Quote:
Original post by Promit
I can't speak for all people, but OGL is a pain to use compared to D3D when you start doing anything remotely serious.
why?
Mainly the lack of anything comparable to D3DX. Rewriting the D3DX math routines alone is a pain. Then you have to do normal and tangent computations yourself, as well as pulling in libraries like Cg if you want to have a reasonable material/shader system without writing long, long custom code.
In addition, the OpenGL API is starting to fall apart. It's kind of hit the edge of its scalability, so things are now getting progressively more annoying. You'll want a example, of course:
glActiveTexture( GL_TEXTURE0 );glEnable( GL_TEXTURE_2D );glBindTexture( GL_TEXTURE_2D, TexIndex );glTexEnvi( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE );glTexEnvi( GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_PRIMARY_COLOR );glTexEnvi( GL_TEXTURE_ENV, GL_OPERAND0_RGB, GL_SRC_COLOR );glTexEnvi( GL_TEXTURE_ENV, GL_SOURCE1_RGB, GL_TEXTURE );glTexEnvi( GL_TEXTURE_ENV, GL_OPERAND1_RGB, GL_SRC_COLOR );glTexEnvi( GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_DOT3_RGB );glActiveTexture( GL_TEXTURE1 );glEnable( GL_TEXTURE_2D );glBindTexture( GL_TEXTURE_2D, TexIndex2 );glTexEnvi( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE );glTexEnvi( GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_CURRENT );glTexEnvi( GL_TEXTURE_ENV, GL_OPERAND0_RGB, GL_SRC_COLOR );glTexEnvi( GL_TEXTURE_ENV, GL_SOURCE1_RGB, GL_TEXTURE );glTexEnvi( GL_TEXTURE_ENV, GL_OPERAND1_RGB, GL_SRC_COLOR );glTexEnvi( GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_MODULATE );All that just to set up the stages for two textures. You can do it in about 1/3 as many lines in D3D. There's so many dumb things here. The need to enable GL_TEXTURE_2D. The constant repetition of GL_TEXTURE_ENV for a function that is called glTexEnv. The inability to modify more than one portion of a 6 argument expression at a time. The need to set an active texture, instead of specifying the affected stage for each call. The need to explicitly enable GL_ARB_texture_env_combine. It's just a royal pain.
fair enuff, i'm not going to argue about it as you do raise some good points, i just wondered t'is all [smile]
The whole DX stinks. Thank god for alternatives. That about sums up the whole DX programming experience for you. I have no idea what I saw in DX in the first place. If you can please use opengl/openal to save yourself some sanity. How can a company that wrote vc6 which I love turn around and produce a dud that DX is? It's like the two aren't even from the same company. Really strange.
Quote:
Original post by JD
The whole DX stinks. Thank god for alternatives. That about sums up the whole DX programming experience for you. I have no idea what I saw in DX in the first place. If you can please use opengl/openal to save yourself some sanity. How can a company that wrote vc6 which I love turn around and produce a dud that DX is? It's like the two aren't even from the same company. Really strange.
Do you have any justification for your argument? Because I assume DirectX doesn't actually smell. Lots of people use DirectX and are happy with it, so throwing that comment in isn't very helpful for someone unfamiliar with DirectX :)
In my experience, it's really nice to abstract the rendering so you can support both OpenGL and DirectX, but assuming you're making a game in your spare time, there's a lot to be said for just picking one and getting the game done. It's cool to have a decent engine design, but what good's an engine design if you never finish anything?
I currently spent the last two months learnign both Direct3D and OpenGL.
I had never touched them before.
With each I made a small renderer and a game prototype.
As far as each go IMO, they are equally capabable. But OpenGL is UGLY (im talking about the language, and the source you produce). It just begs for you to write wrappers for the whole thing.
OpenGL is clumsy and even though it has extensive documentation its not always easy to find.
DirectX is pretty (just as pretty as C++) and if you can read you can make it work.
As far as what to put in an engine. To me it seems like that is determined by what sort of developer you want to be.
If you are an indie developer then go cross-platform and do OpenGL. You'll probably find a better market on Mac and Linux desktops, as they are not saturated with games.
IF you want to make huge commercial games, then I'd say go with DirectX. Possibly for the single reason that huge games are complex, and you can cut the complexity level of design and implementation if you go ahead and cut out supporting multiple platforms and many driver configs. Sadly the easiest way to do that would be stick with MS and DirectX.
As well Direct3d and OpenGl comparision is one thing. But there is virtually nothing to compare to DirectX (direct3d, DirectSound/Music, DirectInput, DirectPlay).
OpenAL seemed great. I messed around with SDL but didnt like it too much, leaving me wishing for DirectInput. I'm not sure what a good cross-platform input library is that supports, any joystick, keyboard layout etc..
Just my 2 cents...
I had never touched them before.
With each I made a small renderer and a game prototype.
As far as each go IMO, they are equally capabable. But OpenGL is UGLY (im talking about the language, and the source you produce). It just begs for you to write wrappers for the whole thing.
OpenGL is clumsy and even though it has extensive documentation its not always easy to find.
DirectX is pretty (just as pretty as C++) and if you can read you can make it work.
As far as what to put in an engine. To me it seems like that is determined by what sort of developer you want to be.
If you are an indie developer then go cross-platform and do OpenGL. You'll probably find a better market on Mac and Linux desktops, as they are not saturated with games.
IF you want to make huge commercial games, then I'd say go with DirectX. Possibly for the single reason that huge games are complex, and you can cut the complexity level of design and implementation if you go ahead and cut out supporting multiple platforms and many driver configs. Sadly the easiest way to do that would be stick with MS and DirectX.
As well Direct3d and OpenGl comparision is one thing. But there is virtually nothing to compare to DirectX (direct3d, DirectSound/Music, DirectInput, DirectPlay).
OpenAL seemed great. I messed around with SDL but didnt like it too much, leaving me wishing for DirectInput. I'm not sure what a good cross-platform input library is that supports, any joystick, keyboard layout etc..
Just my 2 cents...
Quote:
Original post by hplus0603
Thus, you need both if you want maximal coverage.
So if I understand it correctly the reason to implement both is hardware coverage? Or are there other reasons?
Quote:
Original post by HAM
OpenGL is clumsy and even though it has extensive documentation its not always easy to find.
DirectX is pretty (just as pretty as C++) and if you can read you can make it work
Really? I'm a C++ man and I find OpenGL far more "pretty". Though, granted I haven't really looked at DX since version 7/8.
Quote:
All that just to set up the stages for two textures.
One thing I like about OpenGL, is that it seems to be closer to the metal as it were. Talking DX7 level of things now, D3D's texture stages have no relevance on how things actually work.
Quote:
Mainly the lack of anything comparable to D3DX. Rewriting the D3DX math routines alone is a pain. Then you have to do normal and tangent computations yourself, as well as pulling in libraries like Cg if you want to have a reasonable material/shader system without writing long, long custom code.
This actually doesn't bother me, which is strange. I've written my own math routines without much problem ( it's not like it's hard in the first place ). If you don't like Cg, there's always GLSL. If you mean something like the .fx format... Then yeah it is quite a hassle to write your own ( I did - took a while ).
One thing I actually like about OpenGL is the extension system, I think it's just grown on me, or I've just become used to it.
One thing not mentioned so far is the attrictivness (sp?) to employers of being able to use, and showing your use, of more than one API. The majority of game studios that cover more than one platform will use, to a varying degree, their own custom built API.
By showing an employer you are not trapped in one API, and can produce the same outcome with what ever tools you are given is a real plus.
But, and heres my two pence, if your just doing this as a hobby, stick with one for now, you can always abstract the rendering code out later if you want to support more than one API. Want to work on Linux, use OpenGL, windows only, up to you.
I personally have used both, I prefer DirectX simply because I taught myself DX, whereas we had a crappy lecturer at university teaching us OpenGL, and i think that tainted me a bit...
Hope that helps a little
Spree
By showing an employer you are not trapped in one API, and can produce the same outcome with what ever tools you are given is a real plus.
But, and heres my two pence, if your just doing this as a hobby, stick with one for now, you can always abstract the rendering code out later if you want to support more than one API. Want to work on Linux, use OpenGL, windows only, up to you.
I personally have used both, I prefer DirectX simply because I taught myself DX, whereas we had a crappy lecturer at university teaching us OpenGL, and i think that tainted me a bit...
Hope that helps a little
Spree
It's always cool to see the heated discussion of which is better DirectX or OpenGL. 
But the problem is that it is a question of personal taste, and so the discussion is endless.
What I want to discuss is: Use DirectX OR OpenGL in your engine (implement just ONE) or use DirectX AND OpenGL in your engine (implement BOTH).
And how to rectify the (huge) amount of extra work of implementing them both.
But the problem is that it is a question of personal taste, and so the discussion is endless.
What I want to discuss is: Use DirectX OR OpenGL in your engine (implement just ONE) or use DirectX AND OpenGL in your engine (implement BOTH).
And how to rectify the (huge) amount of extra work of implementing them both.
It could possibly be done through a plugin system.
Like you have 2 DDL's (I assume you are making this for the Windows platform, since DirectX is native to Windows). Both have the same routines you can call.
Like Vertex(), Begin(), End(), etc, etc (I know, I know OpenGL syntax, just the lack of knowledge of the DX syntax)...
So you dynamicly link the API you want to use through LoadLibrary function and use the object ot call those functions.
Then those functions do (say for the OpenGL.dll):
void Vertex(...)
{
glVertex3d(...);
}
etc, etc...
Then possibly it's possible to extend your renderer with new API's (I'm 99.9% sure I'm going to learn OpenRT when I can).
Like you have 2 DDL's (I assume you are making this for the Windows platform, since DirectX is native to Windows). Both have the same routines you can call.
Like Vertex(), Begin(), End(), etc, etc (I know, I know OpenGL syntax, just the lack of knowledge of the DX syntax)...
So you dynamicly link the API you want to use through LoadLibrary function and use the object ot call those functions.
Then those functions do (say for the OpenGL.dll):
void Vertex(...)
{
glVertex3d(...);
}
etc, etc...
Then possibly it's possible to extend your renderer with new API's (I'm 99.9% sure I'm going to learn OpenRT when I can).
I am basically doing what mldaalder suggested.
I have a CRenderer interface that describes the basic functionality of a renderer. Then I use class inheritance to buidl a DX renderer and an OpenGL renderer.
I use DLL's so that I can in the future switch between renderers and have everything work. At the moment I am working on the DX side of things since that is what I am most familiar with and will then move to openGL later.
To make this all work though I had to basically extract out the abstract ideas about rendering such as texture stages and different operations that could be applied to them so that the renderers can massage the information into the format they like.
I have a CRenderer interface that describes the basic functionality of a renderer. Then I use class inheritance to buidl a DX renderer and an OpenGL renderer.
I use DLL's so that I can in the future switch between renderers and have everything work. At the moment I am working on the DX side of things since that is what I am most familiar with and will then move to openGL later.
To make this all work though I had to basically extract out the abstract ideas about rendering such as texture stages and different operations that could be applied to them so that the renderers can massage the information into the format they like.
Quote:
Original post by JD
The whole DX stinks. Thank god for alternatives. That about sums up the whole DX programming experience for you. I have no idea what I saw in DX in the first place. If you can please use opengl/openal to save yourself some sanity. How can a company that wrote vc6 which I love turn around and produce a dud that DX is? It's like the two aren't even from the same company. Really strange.
If over 90% of the industry didn't use DirectX and the API was so well designed I might actually agree with you on that idiotic point :) It is also funny you say that as in the latest versions DX has borrowed a lot of ideas and design issues from GL.
Both GL and DX have their place, the only bad point with GL that I have noticed over the years is that games that have been released that aren't by ID users have a harder time playing, etc. A lot of users don't update their drivers every week or two, and I noticed a lot more support issues with GL games versus DX when it came down to drivers.
Obviously that really has nothing to do with GL as an API, but with driver support from manufacturers which I myself count as just as important.
Quote:
Original post by python_regious Quote:
All that just to set up the stages for two textures.
One thing I like about OpenGL, is that it seems to be closer to the metal as it were. Talking DX7 level of things now, D3D's texture stages have no relevance on how things actually work.
I haven't used DX7, but in DX8 and DX9, the texture stages work identically to OpenGL...but the actual syntax is cleaner, less function calls, etc.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement