Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I have an interest in developing games professionally and have started learning DirectX 11 to that end.

I come from a Java background, but with the recent changes introduced with C++11, I've come to like C++ a lot. Coming from Java, I find that the DirectX API reliance on output arguments and a lot of descriptor structs a little disconcerting.

I'm trying to build a framework around the API that returns values instead of using output arguments. The framework also rolls descriptors into the class (e.g. DXGI_SWAP_CHAIN_DESC into a SwapChain class) and internally handles the updating that would be required for any changes. I also plan to use exceptions rather than return codes to handle error conditions.

Is such a framework viable or it just a Java programmer carrying over his coding style into C++?

EDIT: The goals I'm trying to achieve with the framework are that, I want it to rely on returning values, throwing exceptions, handling memory using C++11 and ATL smart pointers. An early iteration of the framework can be found at: https://github.com/Dolvic/DirectX-Classes

share|improve this question
    
What do you find "disconcerting" about output parameters or description structures? It's not that uncommon a technique. –  Josh Petrie Jan 7 '13 at 16:37
    
@JoshPetrie This most likely because of my Java background, but I find it odd that a function needs to modify that many objects. I understand as part of the COM model that returning HRESULTs is the convention, but in a custom wrapper I feel it would be better to use exceptions than return codes. Descriptors don't sit well with me because an object shouldn't require that much of pre-planning just to create it and then sit idle until it used somewhere in the pipeline. I feel it would be better to create an object and then describe it's properties. –  Dolvic Jan 8 '13 at 21:02
2  
@Dolvic: you can't change most D3D object properties after they're created, which is why you use descriptor structs. D3D works the way it does very intentionally, not because of COM requirements. HRESULTs for error detection are also much better than C++ exceptions for a variety of reasons pertinent to what low-level graphics programmers deal with. –  Sean Middleditch Jan 8 '13 at 21:24

2 Answers 2

up vote 7 down vote accepted

I'm trying to build a framework around the API that returns values instead of using output arguments. The framework also rolls descriptors into the class (e.g. DXGI_SWAP_CHAIN_DESC into a SwapChain class) and internally handles the updating that would be required for any changes. I also plan to use exceptions rather than return codes to handle error conditions.

Is such a framework viable or it just a Java programmer carrying over his coding style into C++?

It's certainly viable, and if it makes you more productive in the long run, then it could be a good idea. However I'd advise caution on two points:

  • It does sound to me like you're suffering a little from the "culture shock" of an unfamiliar API design and rather than trying to understand it and immerse yourself in it, you're trying to change it. This isn't necessarily the best approach.

  • Some aspects of the D3D API are that way due to convention (the COM-style API it uses is not an uncommon API design, even if it seems unusual to you), but some are there for very good reasons. Be aware that you could be introducing some subtle performance issues in your transformations of the API in the name of making it "easier" to use. These performance issues probably won't be serious enough to matter, but then again they might be. It's hard to say beforehand.

Finally, wrapper-style APIs don't tend to be terribly interesting from a professional experience standpoint (for example, were you to submit the code to me as part of a job application, I'd probably reject you).

I would advise instead that you try to create an API that builds upon D3D but itself exposes a higher level of abstraction than D3D does -- in other words, don't create something with a 1:1 mapping of every interface in D3D to your new "improved" API style, but instead combine related interfaces (employing them in their native style to help you learn them) and expose something more useful. Two such examples might be:

  • Creating a "model" interface that deals with the vertex and index buffers, textures and shader references necessary to manipulate and render a single logical model to the screen.

  • Creating a "renderer" interface that abstracts away the details of device, context and swap chain set up and management.

share|improve this answer
4  
+1 ...and once you have that high-level API, try to support something else than D3D, e.g. OpenGL. –  Laurent Couvidou Jan 7 '13 at 16:54

It is viable =P, DirectX is low level and COM biased, most of people are not familiar with it. Most of the code you will add will be used only on Creation/Initialization phase, they probably wont hurt the performance (and even if it hurts, the gain you will have in productivity will "pay the price")

Take a look at this: hieroglyph3.codeplex.com

The creator did some of the things you are willing to do (actually it did LOOOTs of more things ), and it worked pretty well !!!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.