Personally, I don't - it's too much of a pain. If the user wants to do something that requires a device recreation (like change adapters or creation flags), then they have to exit and change the options.

Most games seem to follow this behavior. Alternatively, some don't let you change stuff like that at all.

These are what I see as the reasons you might want to be able to reset the device and whether I think each one is worth handling:

Resize the backbuffer, probably in an editor. A good editor is WYSIWYG, so it needs to use the same code paths as the engine, which means the engine needs to support resetting the device as well.

Change graphics settings in-game, like res or AA. I agree with Circlesoft that it isn't a big deal to have the user exit the game, and who wants to support a complicated code path that doesn't add a big feature.

Accidental device loss. I've had this problem quite a few times with other games, say i press shift 5 times on XP or want to force close something the device gets lost. Yes, it would be nice to be able to come back from something like this, but probably not worth the effort.

Switch to ref for shader debugging. This has to be done in-game since you may have to run through half a level to get to what you want to debug. An engine is only as good as its tools, but usually in my experience stepping through a shader isn't necessary to solve the problem. This would be a really awesome feature of any game engine though.

Combined I think this extra functionality is worth supporting resetting the device. It's really not that hard, if you just design the engine with this in mind from the start. Have all objects that create D3D resources inherit from a base that has InitDynamicResources() and ReleaseDynamicResources(). Only allocate and deallocate DEFAULT pool resources here. Store these objects in a data structure and release the resources, then reset, then init. Test this code path regularly throughout development so that you catch offenders early.

Quote:Original post by jamesw
These are what I see as the reasons you might want to be able to reset the device and whether I think each one is worth handling:

There is a difference between having to reset the device and having to totally re-create it. Everyone should handle device resets - it would be far too inconviencing not to. However, complete device recreations happen far less (and are a much bigger pain to handle), so I don't see them as very important. Note that what I mean by a device recreation is to release all D3D resources (completely), including the D3D device.

Some of the items you listed would require a reset, whereas others would require a total recreation:

Quote:Resize the backbuffer, probably in an editor.

This is just a simple reset - just change the presentation parameters.

Quote:Change graphics settings in-game, like res or AA.

This is also in the presentation parameters structure, so just reset the device.

Quote:Accidental device loss.

Yep, just a reset.

Quote:Switch to ref for shader debugging.

This would require a full device re-creation, since you have to change creation parameters. Unfortunately, it is functionality that is quite useful.

Quote:Original post by circlesoft
Personally, I don't - it's too much of a pain. If the user wants to do something that requires a device recreation (like change adapters or creation flags), then they have to exit and change the options.

Most games seem to follow this behavior. Alternatively, some don't let you change stuff like that at all.

What if the user hits alt+tab?
In most cases that will require you to recreate the device...

I really hate it when you're half way thru a level and accidentially jump back to windows, only to find that you cant get back into your game and have to force-quit it...

Yeah, some games disable the alt+tab key as a "quick fix", but there are other ways the same problem can occur (such as pressing shift 5 times, or a background application creating a modal dialog...). Its much nicer to just make your game alt+tab friendly!

Quote:Original post by PhilMorton
What if the user hits alt+tab?
In most cases that will require you to recreate the device...

Yeah, some games disable the alt+tab key as a "quick fix", but there are other ways the same problem can occur (such as pressing shift 5 times, or a background application creating a modal dialog...). Its much nicer to just make your game alt+tab friendly!

I agree, this is completely annoying when applications don't handle alt-tabbing (or similiar behavior) correctly. However, it is important to notice that alt-tab will only reset the device - it doesn't require a total device recreation (and I support properly handling device resets 100%).

In general, these are what would require you to recreate the device:

- changing the adapter the device is created on
- changing the device type (HAL/REF/SW)
- changing D3DCREATE flags

Quote:There is a difference between having to reset the device and having to totally re-create it.

Ah, thanks for clearing that up.

IMHO recreating d3d device is a "must have" for any good game. I would be very angry when playing game accidently press "alt+tab" or "Windows key", and game crashes.

Quote:Original post by SirMike
IMHO recreating d3d device is a "must have" for any good game. I would be very angry when playing game accidently press "alt+tab" or "Windows key", and game crashes.

As mentioned at least twice in the thread, you do not need to recreate a d3d device when the game loses focus.