Jump to content
  • Advertisement
Sign in to follow this  
NathanRidley

OpenGL Abstracting away DirectX, OpenGL, etc.

This topic is 2090 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement

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)

Share this post


Link to post
Share on other sites


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. 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Edited by axefrog

Share this post


Link to post
Share on other sites
You shouldn't worry now about the very low risk worst case of a very unlikely event: you aren't actually planning to replace SharpDX with OpenGL-based rendering or to make them coexist; in case you do it, the SharpDX math library might or might not become unsuitable or an inappropriate dependency; if you really need to switch to another math library, a massive round of editing is going to be easy (the mathematical abstractions are fundamentally identical) and a negligible effort compared to porting the graphical side to OpenGL.

Share this post


Link to post
Share on other sites

As the others have mentioned several times, I would also suggest tackling one of the APIs at a time.  If you can write a renderer in one API, then another renderer using the other API, then you will be moderately equipped to design a system for putting the two together.  Also, keep in mind that your designs will surely evolve as you tackle different challenges, so don't be afraid to experiment and shake things up.  Especially if this is a hobby project - don't limit yourself right out of the gate, but rather challenge yourself to make some big steps in the design!

Share this post


Link to post
Share on other sites
I was very similar to you. When I first started using Direct X 7, I wanted to create an abstraction layer so I'd later be able to support other things, maybe even other OS. Well I still think this is a good idea, at the time I was new to graphics programing and just learning DX 7 was a huge task for me. I never ended up supporting any other API, and when I moved to DX8, I scrapped most of the code anyway. (FYI, first attempts usually suck.)

Now that I've written like 5 or 6 different 3D engines, I've finally think I have enough knowledge to do a multiplatform framework. It's working well, but after I finish this game, I'll probably redesign it yet again.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!