Using DXUT as a framework

It could be, you might need to tweak it slightly to integrate into you game events system.

If can pick up a copy of Game Code Complete, Mike McShaffery uses DXUT as a basis for the book. It might help you to see a practical usage of DXUT.

Yes, it can be used for more than just samples - I tend to use it as the basis of almost everything I create as I simply can't be bothered with the low-level plumbing each time [smile]

The licence agreement marks the DXUT code as 'sample code' and is provided as-is and you can do whatever the hell you want with it.

As for it being bug-free... it is a tested component but I would be hesitant to say it's bug free (is anything?) but as per my previous point, if you find a bug you can fix it yourself or modify the framework to suit your project(s).

hth
Jack

Quote:

Original post by Big_Bear_Scot If can pick up a copy of Game Code Complete, Mike McShaffery uses DXUT as a basis for the book. It might help you to see a practical usage of DXUT.

I have the book :-)
I eventually managed to get his teapot wars to compile, but it was atrocious quality. The book itself is good though.
I'll take another look at DXUT then and see how it goes.

Quote:

Original post by jollyjeffers Yes, it can be used for more than just samples - I tend to use it as the basis of almost everything I create as I simply can't be bothered with the low-level plumbing each time [smile]

Cool, that's good enough for me.
I'm using the Oct 05 SDK, I assume DXUT hasn't changed since then? I looked at the latest MSDN and they had the same old tutorial, so I assume not.

Quote:

Original post by Captain Logic Quote: Original post by jollyjeffers Yes, it can be used for more than just samples - I tend to use it as the basis of almost everything I create as I simply can't be bothered with the low-level plumbing each time [smile] Cool, that's good enough for me. I'm using the Oct 05 SDK, I assume DXUT hasn't changed since then? I looked at the latest MSDN and they had the same old tutorial, so I assume not.

I'd recommend updating to the latest SDK (Feb 2007, although April 2007 should be out soon) if you can anyway, since there's bound to be a few interesting new things and performance benefits over the past year and a half.

Quote:

Original post by Evil Steve I'd recommend updating to the latest SDK (Feb 2007, although April 2007 should be out soon) if you can anyway, since there's bound to be a few interesting new things and performance benefits over the past year and a half.

Yesterday I found April 2007 online (MS website) but I can't find it today on the website. But it said, in the "Additional information" section, that it's using a version of DXUT that works with DX9 and DX10 for all samples and removed the old one.

I never used DXUT but that means that DXUT changed in the last months so you'd better update to that SDK as soon as it is finally online.


JFF


EDIT: I just checked my history in my browser to find out that the download has been removed [depressed].

Quote:

Original post by Captain Logic I'm using the Oct 05 SDK, I assume DXUT hasn't changed since then?

The client side probably hasn't changed a huge amount, but DXUT has definitely changed. Since Dec '05 when the first D3D10 CTP's started appearing it's had more and more v10 features rolled in. I forget the details, but there are some more changes coming up (either Feb'07 or Apr'07) to rationalise this as, in a lot of cases, there are duplicates for v9 and v10.

Download a recent SDK and run a WinDiff on both versions - you'll probably find a lot of changes in the internals...

I would grab a more recent SDK and stick with it - once you use DXUT from a particular SDK you should really stick with that SDK version for your entire project. 99.99% of the time you'll be fine, but there is no guarantee that DXUT in source-code form will compile cleanly on a different SDK.

hth
Jack

Actually, I've had rather bad experience with DXUT, but it was a header translation from C/C++ to Delphi. Mainly, I've found a handful of bugs which make every DXUT component dependent on others (so for GUI, you end up adding XInput and other stuff) and makes it difficult to extend or adapt to your own code. For instance, you can't use GUI without using DXUT itself, unless you modify code and fix the wired code. Also, if you skin GUI components with the supplied DDS example image (which looks exactly as default GUI skin) - some components like slider get broken. In overall, I was pretty frustrated working with it, so threw it off and worked on my own stuff.

Also, can someone confirm that in compiled DirectX SDK samples the special keys like "Delete", selection with "Shift + Arrows" don't work in all samples that use GUI? Because if this is so (at least in my Delphi translation it is), then it's somehow deliberately-induced bug in DXUT GUI: they have code for handling all special keys, but they disable these keys before they reach the handler - I couldn't figure out why (if you comment the code, all keys start to function properly).

Again, I've worked with translations to Delphi, so I can't be sure if it is a bad translation or bugs in the original source code. Although I doubt it's a bug in translation, since Alexey Barkovoy (who received MVP from Microsoft) is pretty good at translating headers.

In my experience, if you want to use DXUT for something other than showing some sample code, you will have to spend days fixing bugs before it will get close to usable, so take this into consideration before deciding to waste your time.

We haven't changed DXUT much since 2005 in terms of interface design, but we do fix bugs on occassion so I recommend a more recent version.

I should note that we did create a new version of DXUT (found in the Samples\C++\DXUT folder) that can support both D3D9 and/or D3D10 depending on what your app supports and the OS/HW you have. The old DXUT version that just supports D3D9 will be going away in a future SDK since the new version is superset of the functionality.

Jason
DXSDK dev lead

Hi
I want to know why they changed the old CD3DApplication class to the DXUT function callbacks? Is there any specific reason for doing this ? For efficiency?

any idea?