Jump to content
  • Advertisement
Sign in to follow this  
MeshMan

State Management

This topic is 4864 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

Hi All, Can anyone tell me how they managed all the render states? I hate debugging for hours and hours to find that it was just something I used like a state block or a sprite object that totally screwed around with weird states. Do you assume a set of states (such as lighting always being enabled) and when a function or object turns it off, you make sure you set it back on for the next renderable? Shaders also carry over states to another effect file. It just seems like a nightmare and it's driving me mad. Thanks, MeshMan

Share this post


Link to post
Share on other sites
Advertisement
Most people have their engine set the render state to some specific known values before objects begin to render. Each object is then responsible for changing this state to fit what it needs to render.

Depending on the states being set, this can range from nearly-free to pretty expensive, performance wise. Most engines imploy some sort of state caching system as well to reduce the number of redundant state changes.

As far as effect files are concerned, you can use them to enforce whatever kind of render state policy you've decided upon. You may decide that you want the effect system to save the current render state and restore it once its done rendering. On the other hand, you may decide that you will let the particular effect do whatever it wants to your render states and then you will set the renderstates back to some known value(s) after rendering has finished.

It seems that at this point you're more interested in eliminating render state bugs than in tweaking performance (which is a very good thing!). So to get you started, I would suggest you write some kind of function to set all the render states you're interested in to some known values and call this function after you've done any kind state changing. Your performance may suffer at first from not using a state caching system of some kind, but at least it will reduce the number of render state bugs you run into.

In general, first make it work. THEN make it work fast :)

neneboricua

Share this post


Link to post
Share on other sites
I have sort of a related question as I'm just now getting around to implementing a "renderer" class that will do just this. So far, all it does is keep track of the current render states and texture states to get rid of reduntant setting.

So I'm wondering, is there anything else important/useful that I should add to my renderer class? I'm using only the FFP.

Share this post


Link to post
Share on other sites
Quote:
Original post by MeshMan
Hi All,

Can anyone tell me how they managed all the render states? I hate debugging for hours and hours to find that it was just something I used like a state block or a sprite object that totally screwed around with weird states.
Do you assume a set of states (such as lighting always being enabled) and when a function or object turns it off, you make sure you set it back on for the next renderable?
Shaders also carry over states to another effect file. It just seems like a nightmare and it's driving me mad.

Thanks,
MeshMan

To make sure that a default render state is reset, after you create the device create and capture a StateBlock. Whenever you need to restore the default state, just call the StateBlock. I doubt you would want to do this for EVERY call, but a few times a loop is probably ok.

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!