Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


XNA Change RasterizerState or BlendState; defensive programming


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 PhillipHamlyn   Members   -  Reputation: 454

Like
0Likes
Like

Posted 31 December 2012 - 11:02 AM

Hi,

 

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.

 

Phillip

 

 



Sponsor:

#2 PhillipHamlyn   Members   -  Reputation: 454

Like
1Likes
Like

Posted 31 December 2012 - 01:11 PM

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 ?

 

Phillip






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS