Sign in to follow this  

XNA Change RasterizerState or BlendState; defensive programming

Recommended Posts



Following advice on this forum I have attempted to reduce the number of graphicsDevice.RasterizerState = and graphicsDevice.BlendState = to allow the device scope for batching all similar calls together. However looking at the way I've done this I'm not happy I understand whether this is good practise in the XNA world;


if(graphicsDevice.CullMode != CullMode.None || graphicsDevice.FillMode != FillMode.Solid)
   RasterizerState newState = new RasterizerState();
   newState.CullMode = CullMode.None;
   newState.FillMode = FillMode.Solid;
   graphicsDevice.RasterizerState = newState;

I do a similar thing with BlendState etc. Although this might be good defensive programming, it does seem a bit odd - I would have thought XNA would check the settings in the new State I'm setting on the graphics device and then only actually inject a state change if the settings were different from the currently found one. However it also strikes me that just checking the "current" State might be an expensive operation (but can't imagine why - as far as I understand this, all I'm doing is injecting a State change into a stream which will actually get executed when I Present())


Does anyone know if this is what actually happens ? Should I implement my own "state cache" to take care of this ? How is this normally done in scene generation code ? How do you defensively program in your object render methods to make sure your objects are rendered correctly, but without excessive state changes ? Do your objects "declare" their preferred rendering States and the scene manager batch them accordingly ?


Thanks for any advice.





Share this post

Link to post
Share on other sites

Partly to answer some of my question; I decompiled GraphicsDevice and it does cache the last Set RasterizerState and BlendState and checks to see if you are changing from the cached one. However both RasterizerState and BlendState are classes and therefore the GraphicsDevice only checks that the reference pointer is the same as the last used - and I can't see that the RasterizerState and BlendState classes override the Equals method to compare the content of the states with each other.


So - I've got some clarity - XNA will cache the last used reference to a graphics resource, but since you cannot change the content of a graphics resource once committed to the graphics device (i.e. change the graphicsDevice.RasterizerState.CullMode directly) you have to create a new instance of the RasterizerState (or other graphics resouce) meaning that XNA will not pick up that Reference A is equivalent to newly created Reference B, meaning its cache is only marginally beneficial.


Do programmers tend to define and manage their own Graphics State caches to aid in defensive programming ?



Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this