Dxut Programming Guide (5): using the main loop through dxut

Use the main loop through dxut

After windows and devices are created, the application needs a main loop (also called a rendering loop or message loop) to respond to Windows messages, update and render scenarios, and process device events. Applications can implement both the main loop and dxut. The registration callback function allows dxut to process devices, frames, and message events.

Enter the Main Loop
To use the main loop of the Framework, simply call dxutmainloop and set the unique parameter to null.
Although the framework is the easiest to process the main loop, it is more advanced to customize a main loop for some more advanced applications. You can use the dxutmainloop function to customize a main loop, but more code is required in the application, such as the following code example:
Int winapi winmain (hinstance, hinstance, lpstr, INT)
{
Dxutsetcallbackdevicecreated (oncreatedevice );
Dxutsetcallbackdevicereset (onresetdevice );
Dxutsetcallbackdevicelost (onlostdevice );
Dxutsetcallbackdevicedestroyed (ondestroydevice );
Dxutsetcallbackframerender (onframerender );
Dxutsetcallbackframemove (onframemove );

Dxutinit (true, true, true );
Dxutcreatewindow (L "basichlsl ");
Dxutcreatedevice (d3dadapter_default, true, 640,480 );

// Custom Main Loop
Hwnd = dxutgethwnd ();
Bool bgotmsg;
MSG;
MSG. Message = wm_null;
Peekmessage (& MSG, null, 0u, 0u, pm_noremove );

While (wm_quit! = MSG. Message)
{
// Use peekmessage () so we can use idle time to render the scene
Bgotmsg = (peekmessage (& MSG, null, 0u, 0u, pm_remove )! = 0 );
 
If (bgotmsg)
{
// Translate and dispatch the message
If (0 = translateaccelerator (hwnd, null, & MSG ))
{
Translatemessage (& MSG );
Dispatchmessage (& MSG );
}
}
Else
{
// Render a frame during idle time (no messages are waiting)
Dxutrender3denvironment ();
}
}

Return dxutgetexitcode ();
}
In this code example, the application calls the dxutrender3denvironment function to let the framework update scenarios and process device events. The application can also completely redo this function, but this is not recommended.

Event handling
The framework uses the callback function to allow corresponding events of the application. The application simply registers a function pointer with the framework. when an event occurs, the Framework calls these functions. The framework does not require all callback functions to be registered, so the application only needs to register the required callback functions freely.
For DirectX rjl 2005 SDK update, the callback function transmits a void * pusercontext from the dxutsetcallback * function to the callback mechanism. This allows the callback function to accept a context such as a class pointer from the application.
Three types occur in the framework.
Device events
Devices may be lost when an application is rendered to a direct3d device. This may be caused by many reasons, such as pressing Alt + TAB to exit the full screen application. Or press CTRL + ALT + DEL, or run another 3D full screen application. In this case, direct3d API notifies the application, which is implemented by returning d3derr_devicelost when a function such as present is called.
When a device is lost, the application has the responsibility to release all direct3d objects (they cannot survive when the device is lost), such as the objects created in d3dpool_default memory. If these objects are not released, the devices cannot be reset when they are returned from the lost status.
The application must wait when the device is lost. When the device returns, the application must call reset to recreate all the device objects that cannot survive the reset process.
Through the framework, this process is simplified. You can use callback functions in applications to handle various device events: device changes, creation, resetting, loss, and destruction. The framework will notice the loss of the device and correctly reset the device when it returns from the loss status. When appropriate, the framework uses the callback function of the application to release and recreate the device object. What the application needs to do is to register and implement the callback function as follows:

Callback registration function	Application callback function	When called by the Framework	Resource Creation	Resource release
Dxutsetcallbackdevicechanging	Lpdxutcallbackmodifydevicesettings	Called before the direct3d device is created. This gives the application a chance to reject the device change by returning false.	-	-
Dxutsetcallbackdevicecreated	Lpdxutcallbackdevicecreated	Called immediately after the direct3d device has been created, which will happen during application initialization and device recreation.	Create d3dpool_managed resources because these resources need to be reloaded whenever the device is destroyed.	-
Dxutsetcallbackdevicereset	Lpdxutcallbackdevicereset	Called immediately after the direct3d device has been reset, which will happen after the device is lost.	Create d3dpool_default resources because these resources need to be reloaded whenever the device is lost.	-
Dxutsetcallbackdevicelost	Lpdxutcallbackdevicelost	Called immediately after the direct3d device has entered a lost state and beforeReset Is called.	-	Resources created in the device reset callback function (Lpdxutcallbackdevicereset ), Which generally implements des all d3dpool_default resources, shocould be released by this application callback function.
Dxutsetcallbackdevicedestroyed	Lpdxutcallbackdevicedestroyed	Called immediately after the direct3d device has been destroyed, which generally happens as a result of application termination or device recreation.	-	Resources created in the device created callback function (Lpdxutcallbackdevicecreated ), Which generally implements des all d3dpool_managed resources, shocould be released by this application callback function.

When the device switches between full-screen and window modes, it is usually reset. But sometimes they need to be re-created by direct3d.
It is optional to call these registered callback functions. However, if the application does not use dxutsetcallbackdevicedestroyed and dxutsetcallbackdevicecreated to register the callback function for device destruction and creation, the framework cannot recreate the device because it cannot notify the application that the device is created or destroyed. In this case, changing the device or switching between Hal and ref will not work.
Similarly, if the application does not use dxutsetcallbackdevicelost and dxutsetcallbackdevicereset to register the device's loss and reset callback functions, the framework cannot notify the application when the device is lost or reset. In this case, if the device object is not in the d3dpool_managed memory, the device will fail to be reset by direct3d.
Note that if the application uses dxutcreatedevice, you do not need to call dxutsetcallbackdevicechanging because the framework will remember the lpdxutcallbackmodifydevicesettings function.

Frame event
The framework also provides frame events, and each frame in the rendering process is called. The application needs to register and implement the callback function as follows:

Application callback function	Callback registration function	When called by the Framework	Scene Rendering
Lpdxutcallbackframemove	Dxutsetcallbackframemove	Called once at the beginning of every frame.	This callback function is the best location for your application to handle updates to the scene, but it shocould not contain in actual rendering CILS, which shocould instead be placed in the frame render callback function (lpdxutcallbackframerender ).
Lpdxutcallbackframerender	Dxutsetcallbackframerender	Called at the end of every frame, or if the window needs to be repainted.	All the rendering CILS for the scene shoshould be specified med in this callback function. After this callback function has returned, the framework will callPresent To display the contents of the next buffer in the SWAp chain.

Message event
The framework transmits window messages, keyboard events, and mouse events to applications through the following callback functions and their corresponding registration functions. Application Programming provides appropriate responses to these events.

Application callback function	Callback registration function	Description
Lpdxutcallbackmsgproc	Dxutsetcallbackmsgproc	Processes window messages from the dxut message pump.
Lpdxutcallbackkeyboard	Dxutsetcallbackkeyboard	Processes Keyboard Events from the dxut message pump.
Lpdxutcallbackmouse	Dxutsetcallbackmouse	Processes mouse events from the dxut message pump.

 

Conclusion: The dxut programming guide has not reached this point, just because someone has already translated this part on gameres and is easy to download in Word format, I have no need to repeat the work. Here is.