Quote:Original post by jff_f I also like D3D because of the design which is "more" object compared to OpenGL where everything is global (many DirectX functions are global but many of the features are available in the interfaces). The interfaces found in DirectX helps me understand what I'm doing in other words, I prefer the device->SetTexture(...) way over the glBindTexture(...) way since I see on what object I'm working. This is not really something I'm goin to use in the decision because wrapper classes will do this trick quickly.
Actually, you could very eaisly argue that State-Based (a particuarly usable kind of "Global") is better than DirectX's Object-Oriented paridigm. Particularly because you can eaisly do OOP with both DirectX and OpenGL - but you can also program eaisly in other ways with OpenGL that DirectX makes much harder.
Just a quick note, a few people here seem to think that DX is portable across PC and Xbox/Xbox360, it's not. I'm not sure about the 360, but the Xbox version of DX was different as it had specialised code. DirectX is about as portable as a grand piano.
---When I'm in command, every mission's a suicide mission!
Quote:Original post by Andrew Russell Actually, you could very eaisly argue that State-Based (a particuarly usable kind of "Global") is better than DirectX's Object-Oriented paridigm. Particularly because you can eaisly do OOP with both DirectX and OpenGL - but you can also program eaisly in other ways with OpenGL that DirectX makes much harder.
As I said it would be easy to make a wrapper so OpenGL reacts like DirectX so it's not what is making me want to use Direct3D. I'm also aware that making a wrapper to make DirectX react like OpenGL would be harder (really slower?)... (I've heard stories about game studios that wrote such wrappers because they couldn't stand DirectX's ways.)
Maybe I should explain more the reasons that make me think about using DirectX...
Having a tested helper library like D3DX that was designed with the API in mind (designed as being a part of it) by those who made the API, that I'm sure I will be having a lot of support if I ever need it is appealing.
The extensions frightens me a bit since I don't completely understand how the system works, not that I don't know how to use them but I don't really understand if an extension will always be backward compatible. I don't like the fact that I may be dealing with extensions specific to some manufacturers. I could just forget about these but it's all the new and interesting features available and will be made available in D3D soon (if not already). DirectX will always provide me the features I'm using since all the new releases are backward compatible this makes me feel more safe with this one.
Those are the main reasons I'm giving Direct3D a try and I think that the same thing happens for others. I have not lost faith in OpenGL and there is no NEED to change API but I found in Direct3D and its helper classes a more easy way to do the same using what is available in the library.
And this is only my opinion to explain what make Direct3D more tempting than OpenGL, opinions from others might differ.
Quote:Original post by frupert and of course the main reason is because OpenGL is generally limited to 60fps.
This is infact the fault of the person writing the software [smile] Its easy to get OGL to go faster than 60fps when v-sync is enabled, its just a matter of asking for it when you swap to fullscreen mode, just that most if not all tutorials never mention this perticular bit of the switch, only covering colour, width and height, and as no one appears to bother to research on their own they never work out how its done. (As you might have guessed, I did and I do know how its done, which is why it was added to the opengl window framework I wrote [grin]).
Quote:Original post by Trienco But in my opinion the answer to "why are most commercial games using D3D" is D3DX. So, when will we see a lib like that for OpenGL and give it a popularity boost?
*chuckles* well, give me time and I dare say I'll get to it [wink]
Quote:Original post by jff_f DirectX will always provide me the features I'm using since all the new releases are backward compatible this makes me feel more safe with this one.
Backward compatible by simply including all previous versions. When I changed my app from Dx8 to Dx9 and had to change every single frigging lock function, because they changed the parameters to accomodate some new features (or maybe just to be a pita?) it didn't exactly feel all that "backward compatible". Extensions are always build on top of the existing thing. Nobody will go and say "hey, this new feature would be easier to implement if we change the way vertex buffer objects work and add 2 more parameters to glVertexPointer.
I don't know how well D3D would take it if half the app uses D3D8 and the other half uses D3D9. Not an issue if you start your project with DxX and finish it with DxX, but if you feel the sudden urge to port to DxX+1 to make use of a new feature you better have your D3D calls nicely encapsulated. And in the end it shouldn't really matter if you check for support of certain D3D features or support of certain extensions. If you try to use something the driver doesn't support they will both crash.
But then, having more or less advanced toys like progressive meshes without coding it all yourself is the kind of tempting and time (read money) saving luxury that is probably making it an easy decision in the commercial world. Or if you just want to get your program done. Though just using an existing engine might be an even plan than worrying about D3D or OpenGL.
My $.02: OpenGL, past the initialization and window setup part is, IMHO, easier to jump into. Not as in decently learn, no, JUMP into. The design philosophy of OGL (GLuint handles, let the driver implement in whatever way it likes, these handles could be indexes into an array, pointers, top secret codes, whatever) is better, again IMHO, than the DirectX object approach. In general, I find OpenGL to have more abstraction over the work done behind your back (GLSL uses varying modifiers to linearly interpolate vars, in short, tex coords. and NV's driver (didn't do much work on ATI) directly translates them into tex coords, and I think ATI also does that, as opposed to the shader programmer assigning them some TEXCOORD# semantic). The thing is, almost anything that can be done in one, can be done in the other, and that's a BIG almost. OpenGL has an advantage in the fact that not each draw call ahs to go into kernel mode (ring 0) and the ICD provider could manage an FIFO queue if he wants, but again, proper D3D programming, and SM3 instancing make this much less of a problem. The fact that MS also decides on the ASM instructions for shader models is too much intervention for me. It should be enough to just define the high level language, and let implementers be free. As for D3DX, it IS useful, but I'd hate to rate an API based on the helper functions the API provider issues. Yes, they're commonly used, but they aren't something to be held as a pro, or con, IMHO. In the end, think about what you'll need, what you'll learn faster, what's more suited with your coding style, and pick that. learn it good. period.
Quote:Backward compatible by simply including all previous versions. When I changed my app from Dx8 to Dx9 and had to change every single frigging lock function, because they changed the parameters to accomodate some new features (or maybe just to be a pita?) it didn't exactly feel all that "backward compatible"
and i'm sure i've heard DirectX 10 is an entirely new interface alltogether..
Quote:Original post by frupert OpenGL is generally limited to 60fps.
No, it doesn't.
I use OpenGL for it's portability and wide girth of features that are lacking in D3D. I also use OpenGL because OpenGL is consistent and orthogonal design, whereas DirectX has changed so many times, it's hard to even imagine why they bother to even call it DirectX anymore. They change the API so often, and so many things break, that if you bought a book on it, most likely the code will *not work* and you will *not be able* to get the SDK for which the book's code was based on.
Quote:Original post by Promit I use D3D for the D3DX library. It's massive, consistent, powerful, and already written and tested.
There are plenty of libraries and Scene graphs for use with OpenGL that are just as good as D3DX in everyway, and mostly better as OpenGL is older and more mature than DirectX. Once you have your foundation set, you rarely need to worry about this anymore, and OpenGL just works consistently, whereas every iteration of DirectX breaks out of the box.
Quote:Original post by phantom *chuckles* well, give me time and I dare say I'll get to it [wink]
Well, you better hurry then, because I will hold my breath and wait right here... and my fridge is way over there. You wouldn't want to be haunted by ghostly images of my starved carcass, would you?
All kidding aside, maybe something like that could be started as forum-encompassing gamedev project. It should have enough independent parts to allow for a couple small groups working on different things.
TextureManager/Loader Geared towards gaming 3d file format Math library Mesh format Loaders for typical file formats (in combination with above mesh) Scenegraph (very specific and complex, but would top what d3dx offers) Gui library (see above)
Might be interesting to see at which point helper libraries start turning into half an engine of their own. I know my last attempt did, when things started to become dependent on other things and seperate "use them or don't" modules weren't so seperate anymore.
I'd throw in a file format draft, even if it ended up a radically striped down 3ds format with uint chunk sizes to avoid the limitations (and 255-character file names). Data-type descriptor bytes instead of a dozen chunk types for all possible combinations, possibility to refer external files for submeshes, material libs, skeletons. Off topic.
