Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Zorbfish

State Management

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

Right now I''m working on a graphic api independent renderer and I''m working on abstacting my state variables. So right now I have one base class:
class IStateVariable
{
public:
    virtual ~IStateVariable();

    virtual void on()
    {
        enabled_ = true;
    }

    virtual void on()
    {
        enabled_ = false;
    }

    virtual void setValue() = 0;

private:
    bool enabled_;
};
From this I just inherit different variables like CullingVariable or LightingVariable. I set the api specific functions in on/off and any specified values (like a specific light) through setValue. The problem is the large explosion of small classes. Considering one for each supported variable, and then two versions of that for OpenGL and DirectX. How do you manage the state of your rendering interface?

Share this post


Link to post
Share on other sites
Advertisement
I tend to abstract this kind of thing at a slightly higher level, to avoid as you say multiple small classes, whose functionality is largely the same.

I think that the best approach is to define a neutral state for your renderer i.e. default values for certain variables, and then for each material, have a setup stage, where you set all the states manually, and then a post-rendering stage where you reset the variables to their defaults, ready for the next material.

Now this can start to get inefficient if you have many materials, but then that''s when you can start to make some of the states persistant across the different materials, by using a manager class of some sort. Texture bindings is an easy one to do, you can keep a record of the currently bound texture, and then simply switch the texturing on and off, no need to bind a null texture before disabling texturing.

Another reason you want to abstract at a higher level, is you will start to find that it just isn''t possible to have exactly the same variables for each different API you wish to support. The problem is that the wrapper isn''t actually hiding any of the implementation details, it''s just changing the interface to a slighty different one.

Share this post


Link to post
Share on other sites
I don''t think there''s anything necessarily wrong with a "large explosion of small classes," as you say. You''re basically providing a seperate get/set function per render state; the APIs use a single get/set function with a state ID number (e.g. D3DRS_LIGHTING, GL_FOG). As I see it there''s little difference.

If it''s a question of managing so many classes, there might be some way to do this using templates (i.e. have the compiler generate the relevant classes rather than having to write/manage them all by hand).

Share this post


Link to post
Share on other sites

  • 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!