This topic is now archived and is closed to further replies.


DeviceObects functions in the Common Files Framework

Recommended Posts

Igilima    122
Hi. I am building something based on the common files framework provided in the SDK. The functions I am curious about are InitDeviceObjects() InvalidateDeviceObjects() RestoreDeviceObjects() and DeleteDeviceObjects(). I can understand the use of InitDeviceObjects() at the start and the use of DeleteDeviceObjects() when exiting the program. It''s the use of these two plus the other two functions in between that I am not fully understanding. Writing all of this out will probably help me to explain it to myself too. I''d like to make sure I understand all of the reasoning behind using InvalidateDeviceObjects()/RestoreDeviceObjects() as well as Init... and Delete... in the middle of the program. I noticed that InitDeviceObjects() and DeleteDeviceObjects() are used (Delete first) when changing video modes. I''d like to verify that this is because the d3dDevice is being deleted and recreated for the new mode? Is it because the d3dDevice ''owns'' the vertex buffers, texture objects etc so they must be recreated using the new d3dDevice when mode changes? It seems like it could be pretty expensive, performance-wise to destroy all those game objects and recreate them when you change screen resolutions. Of course, I understand that you don''t have to destroy the actual objects and recreate them, you just have to destroy the d3d graphics objects associated with them. But still...that could take some doing. My conclusion so far is that I would use OneTimeSceneInit() to create starting game objects and their geometry such as sets of vertices but I would create vertex buffers and other d3dDevice connected stuff in InitDeviceObjects()? That way my game pieces, avatars or whatever remain intact throughout video mode changes while their graphical components are regenerated every time there is a mode change? I noticed that Delete... and Init... didn''t seem to be called when using Alt-Enter to switch from full-screen to windowed and back. However they are called when I use the ''switch modes'' dialog to go from windowed to 1024x768x32 full-screen. Can someone explain why? I suspect it has something to do with a call to ForceWindowed() and purposeful neglect to regenerate everything including the d3dDevice since it is really the same device, just in a window. If anyone would like to give a detailed explanation that clarifies anything I missed about Delete... and Init... I would sure appreciate it. Now, about InvalidateDeviceObjects() and RestoreDeviceObjects(). Why are they there? I am going to try and read a little bit more about them in "Beginning Direct3D Game Programming" but the explanations there seem to be pretty sparse unless I am not reading in the right place yet. As I said, I am using the framework right now to get something going. The author of Beginning Direct3D Game Programming" mentions that a fullscreen framework would be a desireable thing. From what I have seen of the framework code, I should be able to change BuildDeviceList() so that it only locates full screen devices/modes and defaults to creating a device with a fullscreen mode. I know that the framework has code for menu accelerators and other stuff and that would be considered overhead for a fullscreen only game but how serious is the overhead issue with the framework code provided in SDK 8.1? Right now, I plan to take the framework code and just rip out the stuff I won''t use. Is that a bad plan?

Share this post

Link to post
Share on other sites
JoeyBlow2    100
Invalidate and Restore are for when the application loses/gains focus.

If you are running an App in fullscreen. Things are created in video memory with the Init function. However, when you ALT-TAB and go back to windows to read email. You lost your video memory, windows will want the video memory for itself.

So, Invalidate is called by the framework when you lose focus. You have to destroy your objects for windows.

And when you gain focus again, the Restore is called, so your app can then recreate all the objects in video memory again.


When gaining focus, DirectX requires you to call Device->Reset function. If there are any objects in memory, it will fail. You won''t be able to get the Reset function to succeed. If you just ignore it, all of the Device functions will all fail with "NOT RESET" error message. So, you are kinda stuck doing this.

Share this post

Link to post
Share on other sites