🔒 Locked

State Management

Started by Zorbfish Jun 9, 2004 at 7:19 PM 1 replies 1k views

Original Post

Jun 9, 2004 at 7:19 PM

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?

jamessharpe

Jun 10, 2004 at 3:39 AM

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.

superpig

Jun 10, 2004 at 6:11 AM

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).

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.