Open GL vs DirectX

Direct-x has the possibility to be far more detailed than gl using modern versions of windows and ati/nvidia drivers. Incidentally the new ati beta driver has no support for xp, as promised win-xp is no longer supported.

It's already explained before that isn't true. Graphics and effects quality only based on developer skill and your hardware features, no mater what API been used.

Hope this isn't a significant topic deviation.

I understand the obvious choice of OpenGL for cross-platform compatibility, but with the use of Coherent/Webkit, is direct involvement with the underlying graphics API that intensive? Put another way, isn't Coherent/Webkit doing most of the work, or are there still a lot of calls directly against OpenGL?

I read Jon's Nov 22 post (http://www.mavorsrants.com/2012/11/planetary-annihilation-engine.html), but still have that question.

Coherent UI is only used for User Interface, like flash-based Scaleform used for many many other games. Coherent is run in own dedicated process and it's don't even use OpenGL on Windows. Because Google Chrome/Chromium (which Coherent based on) isn't using it on Windows too.

If you press "CTRL+U" in game you will see game without UI, it's all rendered by direct API calls and GLSL shaders.

Stop drinking the Microsoft Kool-Aid . The fact of the matter is that it's technically OpenGL that has the possibility to be more detailed than Direct3D (albeit very marginally, except in the case of Windows XP). Via it's extensions OpenGL has access to many hardware capabilities not available to Direct3D that can give OpenGL benefits over Direct3D. However such extensions are almost always graphics card/brand specific and often still experimental and as such are usually unsuitable for use in a commercial game that needs to support a much wider range of graphics cards. Not to mention that it's rare for them to provide visual improvements as more often than not they they are just meant to provide potential performance increases under very specific uses, though if you speed up something somewhere it does allow you to use the time saved to do something else that improves the visual quality, but as I said it would be very marginal improvements.

In short, as others have said, the difference in quality and even performance between Direct3D and OpenGL is too negligible to matter to any skilled programmer, the biggest factors in deciding which to use are ease of development (in which Direct3D has the upper hand) or the platforms it supports (in which OpenGL has the upper hand).

Extension hell is the reason why nobody likes OGL. It's great if you're that super-cool guy living on the edge, but the rest of us who just want to ship a game would much rather the stability of D3D.

Not to mention that D3D has far superior interoperation with the rest of the world. It's a custom deleter away from being smart-pointer-ready out of the box, for example.

And has a much better integration with the windowing system. I'm no OGL expert, but my friends said you have to use an OS-specific extension for even simple stuff like double buffering. Ouch.

Yeah there's no question that they can be a bit of pain in the *** to set up, but once set up you can fairly easily use them to do whatever you want. There's even several libraries that can take care of managing extensions for you if you don't want to deal with them yourself, and you also have the option of just sticking to the standard which will give you pretty much anything that Direct3D has and not bother with extensions at all. The reason extensions are great is that you can use them if you want or just ignore them, Direct3D doesn't give you any such options, you get what you are given and too bad if you wanted to try something new/different for people with hardware that supports it. If people don't like OpenGL because of the extensions then they are just doing things wrong.

Maybe I'm just too used to being performance minded from my time in PS2 development but generally I find that if you don't need smart pointers then you probably shouldn't use them. There's overhead in using smart pointers and that is exactly the sort of thing you don't want in an API designed to be used for real-time performance, and it's that sort of overhead you don't get forced to use in OpenGL but that exists in a few places in Direct3D. Designing around using smart pointers can make things a lot harder to debug too especially if you get a timing bug, manually managing your memory is usually a lot more reliable when you know what you are doing. Besides it's pretty trivial to write such things if you need them so there's really no reason for that sort of thing to be in the API. But I think I get what you mean, DirectX being object-oriented does make it a fair bit easier to use, especially if you aren't used to graphics programming or coding in a language that isn't object-oriented, it can also be a lot neater than OpenGL code if you don't abstract the graphics API. But once you have a good understanding of how to put together a decent graphics engine I find it tends to be marginally easier to use OpenGL because you get a lot more freedom to do what you need when using some of the more advanced rendering techniques or trying to milk a little extra performance out of the graphics.

That's because buffering is usually controlled by the window of the OS that the game runs in, there's no way around it you have to make similar calls in Direct3D too, and in my experience it's easier to do in OpenGL than it is in Direct3D anyway. There are also several libraries you can use for OpenGL like SDL that take care of most of that platform specific stuff for you, so Direct3D really isn't any better in that regard. Besides when the option is only running on a Microsoft product or running on some Microsoft products and pretty much everything else too, having a few platform specific calls here and there is a relatively minor inconvenience .

I'm sorry, I'mma skip the rest of your post for now, but what the hell are you smoking? Smart pointers don't have overhead. They are exactly equivalent to managing your own memory, but without the massive raft of double deletes and memory leaks. The only even theoretical overhead they have is a couple of function calls, and any non-trivial inliner can easily clean them up.

OGL is even worse than not being virtually smart-pointer-ready out the box, and that's having those horrific GLuints and stuff that don't even have proper types.

As an aside, what did you work on?

Oh you meant simple smart pointers? I hadn't really considered them, but yeah there's not much overhead with them and often not any. I prefer to write code that is clear and explicit though, to make it easier to debug later on, and a simple smart pointer just obfuscates the destruction of an object for a relatively minor convenience, so I don't use simple smart pointers. I'm also not sure how much they would help specifically with the graphics API anyway, most graphics resources are either shared or can be member variables to help avoid cache misses.

I had thought you meant smart pointers with reference counting, which is pretty much the only kind of smart pointer I tend to use, and they do have a fair bit more overhead, but they can be much more useful for a graphics API with things like shared resources such as textures and meshes so I do use reference counted smart pointers there if appropriate for the game. Of course with decent planning it's very easy to just ensure that a set of resources are loaded before they are needed and destroyed once anything that would need them would no longer exist, it's much easier to just have one place where everything is created and another where everything is destroyed, if anything goes wrong it's easy to see why and fix it, and it can help track down leaks much quicker because you know exactly when an object should, or shouldn't exist.

If you have trouble with double deletes and memory leaks then chances are you just haven't got enough experience with C++ to have good code design. When you do things right then even in something as complicated as a game you really shouldn't be taking more than a few seconds to fix those sorts of issues. I can't remember the last time I had a memory leak that wasn't fixed seconds later and I don't think I've ever had a double delete issue that a smart pointer could have ever prevented. Though you do have to set up a decent memory tracker to catch the leaks, but that's something you should do even if you use smart pointers.

True, I've always said that Direct3D was easier to work with to make a game than OpenGL, and Direct3D's proper object oriented approach is the main reason for that. Newer programmers with little experience are going to find Direct3D much more familiar since they have probably only learned a modern and object oriented language like C++, Java or C#, but anyone with any C programming experience isn't going to have any trouble with OpenGL and it's GLuints, it's almost exactly the same as how you'd use objects C anyway. And once you are used to it it makes perfect sense and isn't really any harder to use than Direct3D as long as you aren't reliant on Intelli-sense or your IDE's equivalent to tell you what to write (I must admit to being a little too reliant on it myself ).

On PS2 just 4 regional sports titles for SCEE, you probably wouldn't recognize them unless you lived in Australia or Ireland. They were what I worked on when I first started game development so what I learned working on them has shaped my coding practices probably more that I should have let it . Most of the middleware we used on those projects were written in C not C++ so I got very used to not relying on coding conveniences used in modern modern application development, and having seen what some of those conveniences can do to frame rate on a PS2 now I'm always very wary of using them. I am aware though that with CPUs being so powerful I shouldn't be so concerned with the performance deficits which is pretty much why I said what you quoted .

PS2 was a different animal than a modern PC so some of the habits would definitely be outdated. For example it had serious code cache issues that could make huge performance differences.

We use smart pointers extensive in our codebase. Units referring to other units, projectiles, tools etc. gets to be nightmarish without smart pointers. Ref counted ptrs, weak ptrs etc. are all used. We pretty much don't allow calling malloc/new in the code without a really good reason.

Looks like I'll have to get with the times then , I had a feeling my old practices might not be necessary any more but I was so used to working with naked pointers I never really bothered to look into using the modern conveniences like other forms of smart pointers.

You might bust a gut when you see the number of lamba functions in our code then

I take it you are using C++ 11 then, that's actually another one of the reasons I am not using all these new features, Microsoft in their infinite money grabbing jerkwaddedness decided to make Visual Studio 2012 not run on Windows Vista which is my OS since I needed a 64bit OS before Windows 7 was available, and VS2010 doesn't fully support C++11 , I'd been tempted to see if I can get the partial support it does have working but figured that it would be more trouble than it's worth.
And with that being the case I hadn't properly looked into the new features of C++11, and hadn't even heard of lambda functions till you mentioned it, but now that you mentioned them and I've looked them up I wish I could use them. I'd recently worked on an Android game in Java and loved the anonymous functions, it made callbacks so much easier to work with and really missed them when I went back to C++. Given how useful function pointers and functors are in my games I'm not surprised you'd be using lambda functions all over the place, they would certainly be a convenience I would use if I could.

Edit: Upon further investigation it would seem that VS2010 just needs SP1 to use the C++11 stuff it supports, and it does have some limited support for lambda functions so time for a refactor of the game I'm working on .

Edit2: And upon implementing a lambda function to test that it works it made my game executable "seem suspicious" to my virus scanner :/. Not great but at least it works .

Yeah we are using a bunch of C++ 11 stuff. Honestly without it we may have gone a different direction language wise.

The stuff we use has to work on GCC, Clang and VS2010 so it is a subset of 11.

Any particular reason you're not using clang on Linux to reduce portability concerns?

Shame win32 clang isn't quite ready yet. Once that gets polished, crossplatform builds could be much less painful.

I think by the same reason why they don't use GCC for Windows.

clang on Linux is considerably better supported than the hack that is MinGW supports windows, and MinGW nonetheless provides a basis for many a successful product.

LLVM does have a lot more potential than GCC, and I'm sure in the future it will surpass GCC as the POSIX compiler of choice, but at the moment, GCC is more mature and tends to produce better optimized code. There have been recent tests that show LLVM is catching up, but for now the best choice is to stick with GCC.

As to portability concerns that isn't so big of an issue when comparing LLVM and GCC. (Though technically, GCC is ahead in this department. For now.)

I didn't make the compilers call so I'm not sure but I think it was the path of least resistance. I would love it if we could move to a single toolchain across all platforms. If that happens the obvious candidate would be clang.