Hey Guys,
I know this is a common question. Should I use Direct X or OpenGL?
I have a few specifics I am having issues with. I have spent a lot of man-hours learning and playing with OpenGL, and I understand the basics of both the old and new version. The issue, is when Shaders come in. All my systems have between Nvidia GF 200 and Nvidia GF 400 series cards. Every example I find, even the ones in the NEWEST Superbible do not work on the newer cards, because the newest drivers support a newer version of OpenGL. This is very annoying because I don't want to release a game that people with the newer hardware can't play and vice-versa. I also don't want to make games using older OpenGL, because then I can't take advantage of the newer features.
On the other hand, I hear that Direct X is somewhat more odd in the way it works compared to OpenGL (these may just be opinions). I am also told that Direct X is less efficient, which I can definitely believe. Although, it seems the upside is that there is a LOT of support, it seems to be quite stable, and obviously MOST people use Direct X.
Lets say I make a engine that I want to be multi-platform. Should I currently start with Direct X, and port my drawing code over to OpenGL for portables and Unix-based OSes once OpenGL is done with all its crazy new changes. Or is there another solution you guys can recommend? I love OpenGL, but it just seems that once a new version is released EVERYTHING gets all screwed up.
Thanks a lot guys,
Kurasu1415
Direct X or OpenGL?
Quote:Original post by Kurasu1415
Every example I find, even the ones in the NEWEST Superbible do not work on the newer cards, because the newest drivers support a newer version of OpenGL.
It must have some other reason why the demos don't work. Both nVidia and AMD/ATI drivers still support all older versions of OpenGL. I have a GF260 and the demos work fine.
Maybe you are missing some dlls from freeglut.
Quote:Every example I find, even the ones in the NEWEST Superbible do not work on the newer cards, because the newest drivers support a newer version of OpenGL.
I don't really know where you got this idea, but I suspect that the reason your examples 'do not work' has more to do with issues linking the right libraries than it has anything to do with opengl. All OpenGL that has ever been written (at least in the last 10 years) should still work perfectly fine today, there's no reason why it wouldn't.
Just because a driver updates would not make any programs stop working, and the 'newer versions' of opengl just add some new features, but they don't break backwards compatibility.
I don't really believe that DirectX is more or less efficient, maybe trivially more or less for certain operations, but in the long run they should give you equivalent performance. They're just two API's exposing the same piece of hardware.
You'll find a lot of support for both DirectX and OpenGL, both are very popular.
You say you want a multi-platform engine (of which OpenGL technically qualifies on its own), but I assume you mean multi-API if you want it to run OpenGL and DirectX. I would suggest that if you plan to be multi-api, you have to design around that from the beginning. Once you write the whole engine, you're going to be pretty much stuck with what you have, it's going to be difficult to shoehorn in OpenGL support to an engine that was based around DirectX, at least not without completely forking it and rewriting 80% of the renderer.
If you design around multi-API from the beginning than you can do it, but you might want to spend a little bit of time with each engine on their own first so you can get an idea of where the API's overlap, and how to design your own classes.
Again I'm not sure what "crazy new changes" OpenGL is going through, but I assure they aren't any more crazy than what directX is going through as it progresses through DX9 to DX11 and beyond, all API's must evolve to stay current.
Keep it simple - you say you want it multiplatform, that leaves only OpenGL, go for it end enjoy the ride.
Also, decide on your target requirements. Probably the best way would be to write for OpenGL 3.0+ core or 2.0 but also remembering about 3.0+ core (that is, no fixed-function pipeline). This way, if you ever feel the urge to port to DX10/11, it should be easy enough, as concepts are very similar in both APIs.
Also, decide on your target requirements. Probably the best way would be to write for OpenGL 3.0+ core or 2.0 but also remembering about 3.0+ core (that is, no fixed-function pipeline). This way, if you ever feel the urge to port to DX10/11, it should be easy enough, as concepts are very similar in both APIs.
Author
The bible comes with executables that do not work. They run, but throw OpenGL errors. Many others are having these issues. Apparantly, it has to do with the code because if you look at the twitter page I have comments back and forth with the Lead Author on the book. The person in charge of the chapters is not responding to his emails and he can't fix the Applications. I can compile them with absolutely no errors. I have tried every version on code he has on all my machines using Windows, Mac, and Linux and they still don't compile. I made posts on the forums at the Khronos website and many others are having this issue. I was simply told, "No one can figure out what is wrong."
Also, in regards to the comment on FreeGlut, the issues only come up when non-stock shaders are in use.
Also, in regards to the comment on FreeGlut, the issues only come up when non-stock shaders are in use.
Quote:Original post by Kurasu1415
The bible comes with executables that do not work. They run, but throw OpenGL errors.
I have tried them both under Linux and Windows, they work for me. What error message do you get?
Regardless of the demos, OpenGL application should work on newer hardware. Continue learning the API.
EDIT: I found a demo that does not work. I will have a closer look.
Author
Most from Chapter 9 doesn't work, and nothing from there works. I can post screenshots in a few hours.
I replaced the 1 in the line
with a valid value like WGL_FULL_ACCELERATION_ARB according to the documentations and it fixed the error (Chapter 13 block_redux). For some demos I get only a black or white window. I'm not going to fix all those demos...
Look at the following thread for some newer tutorials:
OpenGL 3.x tutorial
Edit: I missed you post. I don't get any errors in chapter 9, only a black window but I'm pretty sure also that is not a problem with OpenGL itself.
WGL_ACCELERATION_ARB, 1, // must be HW accelerated with a valid value like WGL_FULL_ACCELERATION_ARB according to the documentations and it fixed the error (Chapter 13 block_redux). For some demos I get only a black or white window. I'm not going to fix all those demos...
Look at the following thread for some newer tutorials:
OpenGL 3.x tutorial
Edit: I missed you post. I don't get any errors in chapter 9, only a black window but I'm pretty sure also that is not a problem with OpenGL itself.
The code is just broken. The 3rd parameter in
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, hdrTextures[0], 0);
is GL_TEXTURE_2D while he is attaching a GL_TEXTURE_2D_MULTISAMPLE. This fixed the "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT" error message. There must be at least another mistake somewhere causing the rest of the error messages.
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, hdrTextures[0], 0);
is GL_TEXTURE_2D while he is attaching a GL_TEXTURE_2D_MULTISAMPLE. This fixed the "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT" error message. There must be at least another mistake somewhere causing the rest of the error messages.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
