Sample Framework

Started by
9 comments, last by Permafried- 19 years, 8 months ago
Hi all, After a long time from being out of the gaming scene I've decided to get my game coding head on and venture back into it. I have recently downloaded the summer 2004 edition of DirectX and been looking at its new Framework, I never did use the last one, but this one seems very good. Has anybody used this framework and what are your thoughts on it ? Kind regards, Steve

If it isn't working, take a bath, have a think and try again...

Advertisement
The framework is pretty sweet. Managed coding with C# makes it very easy to make cool effects. Some stuff isn't documented well though and it can be frustrated. If you want to make a full game however, I would use C++ unmanaged to maximize speed and control. But thats just me
Thanks Joeman,

I am using Visual C++ 6.0 which I have been using for many years (mainly for my job). The framework I was talking about is the new Framework Microsoft have developed to allow us to spend less time creating a window, device etc...If you just take a look at creating a device the 'norm' way, it is a lot of code, using this framework, you can just do :

DXUTCreateWindow( L"An example window" );

No need to setup WinowProc, WndClass, although you can override this if you like. And to create a device :

DXUTCreateDevice();

Now normally you would need to use a valid adapter, window handle, set up presentation parameters and furthermore D3DPRESENT_PARAMETERS structure which has many members which are used to set up certain settings (ie, swap effects, backbuffer) which can be very tedious imo.

So, in your WinMain function you could just use :

DXUTSetCallbackDeviceCreated( OnCreateDevice );
DXUTSetCallbackDeviceReset( OnResetDevice );
DXUTSetCallbackDeviceLost( OnLostDevice );
DXUTSetCallbackDeviceDestroyed( OnDestroyDevice );
DXUTSetCallbackFrameRender( OnFrameRender );
DXUTSetCallbackFrameMove( OnFrameMove );

DXUTInit( TRUE, TRUE, TRUE );
DXUTCreateWindow( L"Example Window" );
DXUTCreateDevice( D3DADAPTER_DEFAULT, TRUE, 640, 480 );
DXUTMainLoop( NULL );

Note the use of callback functions, thus for example, when the scene needs rendering, OnFrameRender would be called, when we have lost the device, OnLostDevice would be called.

As an aside I have written my own classes to do this sort of stuff from a while back, stuff like rendering should be set as a pure virtual function, the message loop set as a virtual function, I had never thought of using callback functions, looks good to me.

Steve

If it isn't working, take a bath, have a think and try again...

Yep. The sample code in the SDK, especially the UI and framework, should be designed well enough in terms of both architecture and performance such that its keeps DirectX developers (both professional and hobbyist) from having to reinvent the wheel. That's what we strive for at least. If it’s not up to par, please let me know personally at jasonsa@microsoft.com. We will continue to improve these until there is no question.

Jason
DirectX SDK Development Lead

“This posting is provided "AS IS" with no warranties, and confers no rights.”
Thanks,

Is it possible to use this Framework with Visual C++ V6.0 ? I cannot seem to get a demo app I'm doing using this framework to build ? I have set the project to use UNICODE, added the relevant dxstdafx header, but it doesn't play ball.

Error I get is :

dxutmisc.h(651) : '_noop' undeclared identifier
dxutgu.h(12) : Cannot open include file 'usp10.h'

Kind regards,
Steve

If it isn't working, take a bath, have a think and try again...

Steve, sounds like you need to install the latest Platform SDK
Donavon KeithleyNo, Inky Death Vole!
Thanks Donavon,

I'll go and do that.

Best wishes,
Steve

If it isn't working, take a bath, have a think and try again...

From what we've seen the C# implementation is every bit as "fast" as C++. And since development time for C# seems to be about half, it's an easy winner so far.
Quote:Original post by jasonsa
Yep. The sample code in the SDK, especially the UI and framework, should be designed well enough in terms of both architecture and performance such that its keeps DirectX developers (both professional and hobbyist) from having to reinvent the wheel. That's what we strive for at least. If it’s not up to par, please let me know personally at jasonsa@microsoft.com. We will continue to improve these until there is no question.

Jason
DirectX SDK Development Lead

“This posting is provided "AS IS" with no warranties, and confers no rights.”


OK, everything that follows is IMHO.

Very nice code in the main sample framework file (DXUT.cpp/.h) (60+ printed pages!).

The code involved in providing "thread safety access" to DXUTState is particularly impressive.

Long meaningful variable names + self explanatory code throughout.
The code in these files is a joy to read. Even if a person doesn't use the sample framework directly, it is a good reference
for using the latest SDK.

The top level DXUT code is procedural rather than class (OO) based.
I think this is a good move for a sample framework because a lot of people would like to use various functions from the sample framework without deriving there own classes from a "do it all" framework class.
People could use framework functions as they choose and integrate them in to their own "engine".
Obviously a lot of the top level functions are dependent on each other.
I'm sure all the callback functions could be mapped to "events" in several languages.

DXUTGUI classes:
Nice start, but mapping the functionality of "windows gui control classes" to DirectX classes successfully (other than "trivial controls") is err.., non trivial, like edit controls (exists), tree controls, listview controls etc.
This seems to be "work in progress" as I would expect (not knocking it as I haven't come up with better myself).
CDXUTControl is a nice base class for creating your own "DXUTGUI" controls and I hope you get feedback from users on this (I will myself later hopefully).

One specific question on a gui control function, CDXUTEditBox::HandleKeyboard.
This function seems to "eat" VK_TABS.
I couldn't tab out of this control without altering the source.
In the switch statement for WM_KEYDOWN, the default case code is:

default:
bHandled = wParam != VK_ESCAPE;

I changed the code to:
default:
bHandled = !((wParam == VK_ESCAPE) || (wParam == VK_TAB));

to handle the tab character.

Have I missed something? should I be intercepting the tab character for a CDXUTEditBox somewhere else in my code (Jason?)?

On the whole, the best DX framework I have seen, very nice work!

On the new SDK itself:
Even though the framework itself doesn't "force" the use Vertex/pixel shaders, they are used in most (if not all) samples instead of the Fixed Function Pipeline.
For me this was a good thing as it encouraged me to get into vs/ps programming.
From what I have read, later versions of DX will be Programmable Pipeline only.
Is this correct?

Unfortunately my card (Ti4200) only supports older vs/ps versions, so I need to get a new graphics card, but at least a get a great SDK/API for nothing.

Thanks Jason and the DirectX SDK team,
Cambo_frog


Sorry, forgot to log on for previous message.

Cambo_frog
For the love of god, please tell me that you've just omitted your error checking code for brevity, and you don't really assume that all those functions succeed.

This topic is closed to new replies.

Advertisement