Hi i have been trying to find out what exactly every single function class and interface do. This one has eluded me as it is mentioned no where but in the refrence section which has vary little information. I have also looked on the Internet but with no luck. If some one can help me i would be greatful

You can batch state changes in state blocks. Basically, instead of calling a binch of SetRenderState & SetTextureStageState methods, you can create a single state block at load time and just execute ApplyStateBlock.

To create a state block, you use BeginStateBlock and EndStateBlock. BeginStateBlock tells D3D to record following state changes in a block, and EndStateBlock gives you a handle to that block, with the record of changes.

im not sure what you mean by batching state changes? i understand that you can batch primatives but i had never heard of batching state changes. Why do you batch them in the first place?

Batching state changes means you issue one call to ApplyStateBlock instead of many calls to SetRenderState, etc. It''s more efficient to issue only one call because you don''t have function call overhead and because state blocks may be stored in video memory where video card can access them faster.

I think i understand it now Thanks for your help

There is another much greater benefit of stateblocks used with drivers which handle them properly *:

The D3D API is targeted at a wide range of hardware, and so is an over generalisation of how individual hardware works.

Most hardware DOESN''T map directly to the D3D API. Things which are individual renderstates in D3D are often bits in control registers in the hardware. Many of these control registers have bits to control a few different states. Often these registers are also write only .

When you do a SetRenderState() or SetTextureStageState(), the call goes down to the driver which sometimes caches the states until a render call. Then when you make the render call it **translates** from all these cached states into settings for the hardware control registers.

This translation & remapping takes time, but it does mean that a single state change could require ALL of the internal hardware registers to be recomputed.

In an ideal world*, when you create a stateblock, the driver translates all of the state inside that stateblock into a complete setup for the whole of the chip and then stores this to a block of memory and returns a handle back to D3D. This then means that instead of requiring a full translation of all states when you come to render, the driver simply fetches its pre-translated block of register values (i.e. the stateblock).



* however, this is all driver dependent:
a) if a driver doesn''t support them, then D3D handles them in software, so instead of getting internal translation, D3D still sends all the states in the block down to the driver which then get translated individually. If some of the state in the stateblock is redundant, you end up sending more state than is necessary to the chip so you lose out in performance terms.

b) on some drivers, state blocks can interfere with other driver state management, once again giving worse performance.

c) drivers written around the time of the introduction of stateblocks (DX7 IIRC) can be very flaky. One driver from back then return "S_OK" in response to creating a stateblock, but didn''t actually do anything at all, then when you came to apply the stateblock, once again, the call just returned straight away - thus no states, but no failure codes back to your program.


In summary - if you have a driver which supports them PROPERLY, stateblocks are GOOD, if not they are potentially BAD.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com