Hi all,

I'm looking for an elegant way to design a rendering API abstraction layer, but I keeping running into problems because of OpenGL's bind-to-edit model. For example, one thing I want to do is cache/shadow the current render state to avoid redundant state changes, but bind-to-edit makes this especially difficult.

Here's some pseudocode (I'm pretending there is only one texture unit, for the sake of simplicity):

class Texture {
public:
    void Create()
    {
        glBindTexture(GL_TEXTURE_2D, m_name); // the wrong texture is now bound
        ... // code to create texture
    }
    GLuint GetGLName() const { return m_name; }
private:
    GLuint m_name;
};

class GraphicsDevice {
public:
    void SetTexture(Texture* texture)
    {
        if (texture != m_texture) {
            glBindTexture(GL_TEXTURE_2D, texture->GetGLName());
            m_texture = texture;
        }
    }
private:
    Texture* m_texture;
};

As you can see, the texture class needs to bind itself in order to create the OpenGL texture object, and so the the GraphicsDevice class now thinks a different texture is bound than the one that actually is.

The obvious way to fix this problem is to add a glGet(GL_TEXTURE_BINDING_2D) call in Texture::Create so that the previous texture can be bound afterwards, but glGet() calls are supposed to be avoided, right?

The only other solutions I can think of involve various ugly techniques such as circular dependencies, global variables, etc.

Is there a better way of solving this problem?

Direct state access does indeed look like a great solution, but I think the hardware requirements might be a bit high. Interesting point about whether glGet values will be cached -- I'll remember that.

It really depends on the GL version you're aiming to support. Suppose it's 4...

That technique looks excellent, but unfortunately I need to support Mac OS X versions earlier than Lion, so I only have OpenGL 2.1 available. If you have any suggestions that could work for OpenGL 2.1, that would be great. I'm interested in your idea about having the device create the textures. How would you implement this? Would you just create the OpenGL texture object in a function in the GraphicsDevice class and then pass the GLuint into the Texture constructor? Or something else?

if you have to resort to glGet to query the state, then your design has flaws

Yeah, that's what I thought. Do you have any pointers on how I could approach re-designing this so that I wouldn't need to use glGet?

Thanks!

Ok, that solution sounds good.

However, one thing I just thought of that could be a problem with both these designs is texture deletion. Once the Texture instance is destroyed (either with the delete keyword or when it goes out of scope) won't the GraphicsDevice class have a dangling pointer? For example, if you called CreateTexture2D() and the object pointed to by m_texture had been deleted, when the GraphicsDevice instances tries to restore the previously bound texture, it will be calling a member function of a deleted object, causing a crash.

Do you have any ideas on how to fix this issue?

Also, what's FL9? I googled it but I can't seem to find anything.

I have most of my resources pointed to as shared_ptr's. I know it is not the best solution but it works for now.

Also why do you need to cache the rendering state? In my code, a list is prepared containing all things to be rendered this frame. Then it is sorted to reduce state changes

and then rendered in a single function removing the need to store a global cache.

Ok, that solution sounds good.

However, one thing I just thought of that could be a problem with both these designs is texture deletion. Once the Texture instance is destroyed (either with the delete keyword or when it goes out of scope) won't the GraphicsDevice class have a dangling pointer? For example, if you called CreateTexture2D() and the object pointed to by m_texture had been deleted, when the GraphicsDevice instances tries to restore the previously bound texture, it will be calling a member function of a deleted object, causing a crash.

Do you have any ideas on how to fix this issue?

Also, what's FL9? I googled it but I can't seem to find anything.

Thanks for the replies!

I have most of my resources pointed to as shared_ptr's. I know it is not the best solution but it works for now.

Also why do you need to cache the rendering state? In my code, a list is prepared containing all things to be rendered this frame. Then it is sorted to reduce state changes

and then rendered in a single function removing the need to store a global cache.

This would definitely work, but I just prefer it if the caching is implemented in the graphics API layer, so that the user doesn't have to worry about it. It seems to me that you might end up implementing render state caching multiple times, for each type of graphics you need to draw; e.g., the actual game world, the UI, etc. I also think this could pose a problem if you are dynamically generating geometry -- i.e., filling a vertex buffer with data, then drawing it, filling it with new data, and so on. How would you have a list of objects in this case?

Ok, that solution sounds good.

However, one thing I just thought of that could be a problem with both these designs is texture deletion. Once the Texture instance is destroyed (either with the delete keyword or when it goes out of scope) won't the GraphicsDevice class have a dangling pointer? For example, if you called CreateTexture2D() and the object pointed to by m_texture had been deleted, when the GraphicsDevice instances tries to restore the previously bound texture, it will be calling a member function of a deleted object, causing a crash.

Do you have any ideas on how to fix this issue?

As a general rule, anything responsible for allocating memory should be responsible for deleting it: void GraphicsDevice::DestroyTexture(Texture t) { ... }

This is a good idea. What's interesting though, is the texture class doesn't really do anything in this case -- it just stores a texture name and returns it. Also, if you need an instance of GraphicsDevice to destroy a texture, it would then be necessary to pass a pointer/reference to it around more. For example, if an object creates a texture in its constructor, and destroys it in its destructor, it would need to maintain either a pointer or a reference to the GraphicsDevice, so that it could call DestroyTexture. This wouldn't be needed if you could delete a texture without needing the device, but I'm not quite sure how to get around this.

[quote name='max343' timestamp='1356428689' post='5014135']
FL9 is feature level 9 mode of D3D11.
[/quote]

Ah ok, I'm not too familiar with D3D terminology.

[quote name='max343' timestamp='1356428689' post='5014135']
As for your first question, then yes it could potentially cause a problem, though this problem is much easier to identify with a simple assert during bind, just check whether the texture name seems valid (for instance, you can keep track on how many textures you've allocated).
This way of deletion is just how D3D does things, you don't have to do the same. As Aldacron already said, your GraphicsDevice can handle the deletion (and check if what you're deleting is currently bound). However, as far as the state goes textures can delete themselves because for that you don't need to bind them (you don't alter the state).
[/quote]

I'm having trouble understanding how this would be implemented. How would you get the texture name without calling a function of the Texture object (which might have been deleted)? I'm also not sure how keeping a count of the number of textures allocated would help you determine whether a texture name is valid. I thought OpenGL wasn't required to return a contiguous range of texture names. I do like the idea of being able to model D3D on this -- could you maybe give a simple example of some code for this? Many thanks.