I'm a bit torn. I'm just learning graphics programming, but I want to make sure I use good practices as I go. Typically, when writing a web/business application I would separate the presentation layer from the business layer (typical 3-tier design) and ensure that the different layers are loosely coupled, with a proper separation of concerns between the different components and so forth. That is all old-hat to me, but game programming is new, so I'm trying to work out what might be different than how I'd normally approach things, due to performance concerns and other game-specific problem areas.

In my case, I'm using SharpDX, which exposes DirectX via a managed wrapper, and it provides a bunch of really useful classes, such as SharpDX.Vector3, which has a whole lot of handy utility methods, mainly for performing various types of transforms.

Despite its usefulness, I feel like I should not use this in my game because it will force me to reference SharpDX which will sting me if I decide to swap in OpenGL for rendering. Or am I thinking too low-level, and really I should be wrapping the actual vertex structures I use as well so that anything dealing directly with a vertex is more of a rendering engine detail?

Any tips, advice, pointers to good articles, etc, would be appreciated.

Seems the search feature could have come in handy before I posted.

Specific to my question:

http://www.gamedev.net/topic/546381-abstracting-graphics-libraries-from-the-game-engine/

Similar questions (and answers):

http://www.gamedev.net/index.php?s=16ccd0198d5732e4da4c2d8f3348cc0c&app=googlecse#gsc.tab=0&gsc.q=abstracting

I'm just learning graphics programming...

Not to discourage you, but don't worry about abstraction if you are just a beginner. You'll proabably change your design a couple of times even if you're focusing on only one API.

As your graphics understanding improves, so will your design and code quality.

I think it's important at this stage to decide if supporting OpenGL in the future is something you actually want to do.

A lot of people start out with the idea of supporting OpenGL (or DirectX if they start out with OpenGL) at a later point in time in their rendering engines; this results in them trying to write an abstraction layer on top of their original graphics API which doesn't really do the underlying API any justice.

Designing a proper wrapper exposing the functionalities of both APIs to their fullest extent is HARD. It's going to require a complete understanding of both APIs, their designs and their quirks. Add to this that you'll have to design a system which will unify these sometimes completely different beasts into a single API without introducing too much overhead and without sacrificing functionality.

If you really do want to support both you could always check out some third party utility libraries for doing vector math and such, I'm sure there'll be plenty of those out there.

If support for multiple rendering APIs isn't an absolute must I just wouldn't worry about it and work with the tools provided by SharpDX; no need to put a lot of effort into something which eventually won't have that much of an impact on your end result (ie. your game)

Thanks for the advice, and I think you're right. Back when I was learning to program, I often made the mistake of trying to abstract away too many things without having a proper understanding of the APIs and frameworks with which I was dealing, which usually led to a very poor abstraction and the inferior reinvention of multiple different wheels that already existed. The Windows market is plenty big enough that I should be happy to service that market for my first few games while learning. I can worry about engine abstraction at a later date when I have some decent experience writing games.

I'm just learning graphics programming...

Not to discourage you, but don't worry about abstraction if you are just a beginner. You'll proabably change your design a couple of times even if you're focusing on only one API.

As your graphics understanding improves, so will your design and code quality.

Thanks, and I agree. I'm going to stick with SharpDX and Windows exclusively for now.

Hi. Professional game developer with ten years experience here. I totally agree with the previous posters who say that trying to write a good quality abstraction layer between opengl and directx will be an uphill battle and probably not the best use of your time.

Having said that, in your original posting, you mentioned that you were finding the vector math packages of sharpDX handy. Even though you have made the decision not to use an abstraction layer for graphics, that does not mean that you need to tie the non-rendering parts (e.g. your AI code) of the game to SharpDX's math library. While writing your own rendering abstraction layer might be a formidable challenge, writing your own vector math routines is not that hard, or you could probably find some good ones that are not tied to a particular rendering engine. If you avoid tying your entire game to directX math libraries then it would mean that if you do decide to port it to another platform you can just replace your rendering code and the rest of your code will not need to be gutted, everywhere that it uses math routines.

On the other hand it might be the case that the sharpdx math library is separate enough from the rest of sharpdx that it would be possible to use it alongside some other rendering library based on opengl. I'm not familiar enough with sharpdx to know if that's the case, but if the math stuff is a separate DLL then that would be a good sign

Hi. Professional game developer with ten years experience here. I totally agree with the previous posters who say that trying to write a good quality abstraction layer between opengl and directx will be an uphill battle and probably not the best use of your time.

Having said that, in your original posting, you mentioned that you were finding the vector math packages of sharpDX handy. Even though you have made the decision not to use an abstraction layer for graphics, that does not mean that you need to tie the non-rendering parts (e.g. your AI code) of the game to SharpDX's math library. While writing your own rendering abstraction layer might be a formidable challenge, writing your own vector math routines is not that hard, or you could probably find some good ones that are not tied to a particular rendering engine. If you avoid tying your entire game to directX math libraries then it would mean that if you do decide to port it to another platform you can just replace your rendering code and the rest of your code will not need to be gutted, everywhere that it uses math routines.

On the other hand it might be the case that the sharpdx math library is separate enough from the rest of sharpdx that it would be possible to use it alongside some other rendering library based on opengl. I'm not familiar enough with sharpdx to know if that's the case, but if the math stuff is a separate DLL then that would be a good sign

Cool, thanks for the advice. One concern I had was that to interoperate with DirectX I'd have to use its own math structures, which would mean copying from my own to DX, then going from there, which seems like a wasted step, but I actually now think I'm mistaken, as it looks like I really can copy any data into a buffer; it doesn't need to originate as a DX Vector3 or whatever. While learning though, I'll probably, for now, still stick with SharpDX math structures, then as soon as I'm ready, start using my own, because that will have the added benefit of forcing me to rehash the linear algebra knowledge I've been learning, and mentally associate the different seemingly-abstract operations with their practical applications in 3D programming, which will help drum that knowledge in. All the sources I've been reading/watching so far seem to separate the mathematical principles from the application, which means while i'm trying to learn all the relevant knowledge prerequisites in, say, matrix algebra, i'm not absorbing it as well as I should, because the theory doesn't talk much about how a given operation actually applies in the real world which means all I see is a bunch of abstract operations, many of which don't seem to have any obvious purpose.