Managing state
While I have been developing the tutorials and learning OpenGL, it has become obvious that managing state, both game state and OpenGL state is important. From an OpenGL point of view, being able to identify what state its in such as the currently bound texture, blending options etc is important.
Querying OpenGL for this information is very expensive and not something to be done, at least often, within the core game loop. For this reason it becomes necessary to store and manage that state yourself.
Having done some research I’ve decided to introduce a Singleton class in my code to perform this function. This is a basic option which is configured to only alloc and init once, like a static class in Java. This then allows me to configure state variable within this class as well as provide global functions I may want to perform on those functions as well. I can then just access the single instance of that class which exists to retrieve that data.
In the current version of the Image class I am querying the currently bound texture which is expensive, so I am going to remove this and check the currently bound texture being managed by own code.
I don’t have access to my code at the moment, but I will post some more information on what I have done to get this working ASAP. I’ll also look at how I can build it into a tutorial, maybe when I cover the structure changes to the project.
Hope that makes sense :o)
Mike
4 Comments
RoberRM on May 15th, 2009
Hello again, Mike:
One quick question (that I don’t know where to post, so I post it here because it’s performance related): in some cases we are creating a function that calls to another function and this one to another function (for example, [h doThis] calls to [h doThisWith:1] which, in return, calls [h doThisWith:1 and:1]. Wouldn’t it be better to only implement the last method and whenever you need to use [h doThis] use [h doThisWith:1 and:1] instead?
My guess is that the improvement is too little to notice, but I don’t see the harm in doing this and you can gain a small speed boost, can’t you?
mike on May 15th, 2009
Hi RoberRM, you are right, there is nothing stopping you only implementing a single method which takes all the possible parameters at once. I’m not sure you would even be able to measure the speed boost by doing it as it would be very small :o)
This is more a personal preference I suppose. The extra method signatures are there for convenience and I think it also makes code which uses that class easier to read. Rather than having large method calls which contain lots of unused default settings all the time, you can just call the method with a signature that contains the important settings you do want to change. That’s the only reason I’ve create some extra methods in classes such as Image really :o)
Mike
mike on May 15th, 2009
I’m just encoding a tutorial on creating a Singleton class to manage state and it will then be posted.
Mike
mike on May 15th, 2009
Got my singleton class instance working now so I can track state between classes easily. I’ll be posting a small tutorial on this soon :o)
Mike