It has been a while since my last post. After my little adventures on graphics programming, I’ve been quite busy with work lately so I haven’t been able to continue working on my little Pulse Library. Although, I’ve been thinking on what to move on next with my library for a while now. I have two choices. First, either work on the 2d stuff for now. Basically setting up basic rendering and hand written sprite system. This will also be the foundation for one of the things I’m also planning in the future: GUI or Graphical User Interface system. The second choice is simply to go directly to 3D first. Since DirectX pretty much works on 3D it would be easier for me to start on this direction. BUT WAIT! While I was too busy thinking about which way to go first, I totally forgot one really important thing! A resource manager! I can’t just start writing all these systems up and use resources like crazy. I need a way to properly manage and dispose resources. I have already started writing about half of the manager last weekend and I’m hoping to finish it by the end of this week so I can finally ACTUALLY start working on my render ( then figure out on which direction to go… 2D or 3D ).
I’ll briefly discuss the manager in here for now and I’ll be posting another blog post discussing how my manager was designed and how it is used in detail. It would be nice if I can display pretty nice UML pictures in here but I’m lazy. So deal with it! I should start using UML next time though… Actually I just forgot how to use it and I need to review my software architecture class regarding on how to use it again. 😛
So here’s how my Resource Manager goes:
The whole manager uses a monolithic management structure that consists of a number of resource management subsystems(we’ll get to this later). This system is designed to have a one and only instance used throughout the time an application is run. That means we’ll be using a singleton design pattern.
When i say monolithic management structure, this system will literally handle ALL resources used by the application. Let it be partial streamed packets for sound and or music, game data objects (game data will be stored in a resource cache), graphics resources like textures, vertex and index buffers, shader effects etc. Yes, ALL TYPES OF RESOURCES.
Okay, so the problem with this approach is that how the hell will we able to do that?! Different types of resources requires radically different types of interfaces and if we merge them all to one, it’ll just result in one huge convoluted type of manager class interface that more than half of its methods doesn’t make any sense. In order to fix this problem, we need to study each resource type and try to derive a number of methods that’s pretty much being used by all of them. So what we need to do is basically build a VERY GENERIC type of resource base type. In my current implementation, I simply call it as a ResourceItem. The ResourceItem class contains abstract methods that derived classes will need to define. Some of its methods will be like Create(), Destroy(), Disable(), Restore(), LoadResource(), SaveResource(), etc…
So while the manager hands out different types of resources based on our needs, internally, the manager doesn’t care much about what type of resource it is. All it cares is that its handling a ResourceItem and all the basic methods that it needs to create, maintain, and finally destroy are there. Simply as that!
This pretty much lays out the general idea of the manager that we will be using. Now for the resource management subsystem that I mentioned at the start, this is simply a storage pool. A storage pool is a container I specifically designed to store game resources. It behaves like an array that issues handles to new added resources. This storage pool is also a dynamic container that increases its storage size whenever needed. The difference is that, due to the huge performance hit by arrays, it uses a linked-list instead. Now we all know that linked-lists suffers huge cache misses during traversal. So the storage pool that I will be using uses a different trick. Instead of using linked-list per object, we use linked-list to link chunks instead. The keyword here is chunk. We allocate chunks or blocks containing a number of objects and when that chunk is full, we then allocate a new chunk and link the new one at the back of the list. Isn’t it cool? Such a simple design now actually has the best of both worlds(array and linked-list)!
Well, that’s all for now. Sorry if most of this doesn’t make much sense as of the moment. My mind is still a little fuzzy with this either. I’ll post an update with more details to come when I finish working on this.
And here’s a random happy music for you!
Have a great day!