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?

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.