Sign in to follow this  
steg

Sample Framework

Recommended Posts

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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


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


Share this post


Link to post
Share on other sites
A lot of people seem to be saying elsewhere that they dislike the new framework, that they preferred overriding the virtual class and implementing things this way.

I'd have to disagree as this kept you to a much too linear approach, whereas the current callback implementation allows me to set the callback anywhere in the code I wish, as long as I have the prototype, thus allowing me to enable my networksend and recv callbacks for example only after my network layer has been created.

The GUI system is excellent and should save a good number of people loads of time (I know it did me) when it comes to developing quick and comprehensive menu systems, though a performance boost to them would be nice, not to mention the use of the MsgProc() kind of slows down the execution of the application. This is the first iteration of them though and I have to say I'm very happy with how they're implemented and function, besides the lack of any real comprehensive documentation.

All in all, I'd have to say I prefer the new format over the old one, and with a few tweaks here and there it can function almost any way that you want it to, without adding too much overhead, or killing it's implementation.

Permafried-

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this