🔒 Locked

To use DXUT or not to use DXUT?

Started by BenS1 Sep 2, 2010 at 4:16 PM 4 replies 9.4k views

Original Post

Sep 2, 2010 at 4:16 PM

Hi,

I'm just starting work on a new game project, my first with DirectX 11. I notice some of the samples use straight DirextX code and others use DXUT as a framework.

So here are a few questions that hopefully you can help answer so I know which direction to go:

1. What do most of you use, DXUT or straight DirextX code?

2. Can you happily mix the code? For example, don't use the DXUT framework but still use DXUT utility functions if you need them?

3. Many years ago I wrote a game in DirextX 5 (I think), however the DirextX 5 code no longer works (Unsurprisingly). I would have liked to have updated my code to use DirextX 11, but the game code and the DirextX 5 were so tightly knitted together that it looked like a massive job. To avoid the same problem this time I want to abstract the graphics code away from the engine code... so in theory I could create a DX11 render, a DX9 renderer, maybe even an OpenGL renderer and in the future maybe a DX14 renderer!

The problem with DXUT is that its more than just a graphics layer, its a compelte framework. It handles keyboard and mouse input, MsgProc's etc. This makes it difficult for me to abstract the graphics code away from the input handling and general engine code. What are peoples thoughts on this?

4. I've looked through the DirectX SDK (June 2010) documentation and it appears that only DXUT is documented and DXUT11 is mentioned but not fully documented. Has anyone else noticed this?

Thanks
Ben

XeonXT

Sep 2, 2010 at 4:57 PM

Though I am by no means an expert on DXUT, my thoughts are as follows - the more you write yourself, the more manageable everything becomes. I've always stayed away from DXUT simply because it doesn't fit my coding style AND I like the feeling of having written things myself. In this way, I know exactly what I can or can't expect from them each function.

I suppose the bottom line is that it really depends on what you want to achieve. Yes, a generalized/abstracted framework written by you and not relying on DXUT is going to get far more mileage than a quick mash-up of DXUT and your own code. But it will also take a great deal of time and frustration to get right, whereas picking up DXUT might be easy for you.

I would say that if you're just working on a simple, one-time project, then use what feels comfortable and simple for you - if that means DXUT, so be it. If you're working on a large project or think you may work on other, similar projects down the road, it'd probably pay off in the long run to invest some time into writing an abstracted framework.

SimonForsman

Sep 2, 2010 at 5:05 PM

Quote:
Original post by XeonXT
Though I am by no means an expert on DXUT, my thoughts are as follows - the more you write yourself, the more manageable everything becomes.

My thoughts are exactly the opposite, the more you write yourself the more code you have to manage yourself and the more bugs you're likely to get.

If DXUT does what the OP needs he should use it, no point in reinventing the wheel unless you need a different type of wheel.

XeonXT

Sep 2, 2010 at 5:26 PM

Quote:
Original post by SimonForsman
My thoughts are exactly the opposite, the more you write yourself the more code you have to manage yourself and the more bugs you're likely to get.

In many cases, though, it's a trade-off between getting bugs because you wrote the code incorrectly and getting bugs because you didn't understand how to use the code that somebody else wrote correctly. As I said, it's really a stylistic choice and entirely depends on how you're used to programming.

Quote:
Original post by SimonForsman
If DXUT does what the OP needs he should use it, no point in reinventing the wheel unless you need a different type of wheel.

Certainly! As long as he thoroughly understands how to use and manage the wheel. DXUT is more of an entire warehouse of wheels, which is why I advise caution. It has a lot of functionality, and that same functionality can get in the way when it isn't needed or when it isn't understood, which seems to be the most common problem caused by utility libraries.

Again, mostly a choice based on what the programmer is used to and how well DXUT fits (or doesn't fit) his/her style.

BenS1

Sep 3, 2010 at 3:27 AM

Thanks both

I agree with various points you both made, but in general I have to say that the DXUT framework doesn't really fit my coding style. It feels quite messy (As the sample code demonstrates).

I'd be happy to use some DXUT functions as just utility functions, but I probably don't want to use the entire DXUT framework.

Do you know if the DXUT functions are safe to use in isolation, or are you forced to use the whole DXUT Framework if you want to use any DXUT functions? For example it would be useful to use the CDXUTTextHelper class for outputting debug info to the screen.

Thanks
Ben

RythBlade

Jan 22, 2012 at 9:18 PM

HI!
I see this thread is getting a bit old now so I was wondering what you settled on how the project went. I'm in the same situation you were. I've already done a project using raw DX11 that was sucessful but didn't require any sort of real GUI implementation. I'm about to start the main development on a large university project that is going to require quite a lot of GUI stuff so whatever I do will be from scratch. I'm confident I could abstract DXUT or raw DX11. I could easily develop these myself but I'm wary of the time overhead. I guess I'm wondering if you used DXUT and what performance overhead there was on some of the libraries. Also how restrictive was it?? How intuitive would it be to add further GUI elements.

Also has anyone else got any experience with DXUT and raw DX11 that could give me a comparison??

Thanks very much

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.