Jump to content
  • Advertisement
Sign in to follow this  

XNA Change RasterizerState or BlendState; defensive programming

This topic is 2114 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!