Is DX9 device reset() expensive?

[arch]

Newbie question:

This is in a C# context, btw. I modify lots of properties on the Microsoft.DirectX.Direct3D.Device before rendering different components and frequently need to reset these settings back to some known baseline before rendering a different component. Is the the Device.Reset(PresentParameters) a suitable way to do this? Will it set things like RenderState and SamplerState back to the same state every time? And more importantly, is it expensive (in terms of performance)?

[Axel]

Calling IDirect3DDevice9::Reset causes all texture memory surfaces to be lost, managed textures to be flushed from video memory, and all state information to be lost. Before calling the IDirect3DDevice9::Reset method for a device, an application should release any explicit render targets, depth stencil surfaces, additional swap chains, state blocks, and D3DPOOL_DEFAULT resources associated with the device.Does that sound inexpensive?

[arch]

I see your point... ah well I suppose I'll just save previous settings one by one before twiddling anything and set them back when I am done with the device so that the next piece of render code is not affected by me leaving the device set in a funky way.

[roel]

from directx9_m.chm:



// begin recording device state
device.BeginStateBlock();

// tell device the states and values to record
device.RenderState.FogStart = 0.3f;
device.RenderState.FogEnd = 100.0f;
device.RenderState.FogColor = Color.Gray;

// stop recording device state
StateBlock sb = device.EndStateBlock();

// save device states recorded above
sb.Capture;

// change device states
device.RenderState.FogStart = 2000.0f;
device.RenderState.FogEnd = 35000.0f;
device.RenderState.FogColor = Color.Yellow;

// render scene w/changed states
device.DrawPrimitives();

// restore device's saved states
sb.Apply();

// render scene w/saved states
device.DrawPrimitives();

[arch]

Thanks!

I read up on the stateblock and it looks like what I am after. The only (minor) downside is that it only saves state that I specifically record. If there is a piece of code that twiddles something that isn't in the stateblock then, of course, it doesn't get reset when the stateblock is applied. This just means I'll need to continue to update my baseline stateblock as I write bits that twiddle something new.

Thanks again.

[arch]

A little note on this topic, the above Microsoft example is flawed.

First of all, they reference sb.Capture as if it is a property (it is a method) so they obviously didn't compile the example code snippet.

Secondly, you don't need to call sb.Capture() if you are using BeginStateBlock()/EndStateBlock() - in fact it really screws things up. After capturing state with StateBlock sb = device.EndStateBlock(), simply calling the sb.Apply() method will replay the recorded settings whenever desired.

With this said, StateBlocks are exactly what I was after.

[roel]

i'm sorry for stealing that invalid code from ms :)