It’s (about) a week since my last post introducing my plans for the Asset Manager I’m constructing as part of the Tyr game engine, so what has happened?

Short answer: Not much, long answer: Re-factoring!

When  I first started working on the Asset Manager, I was learning the ropes of SQLite (which is rather good) and re-learning SQL syntax (it’s been a while since I’ve had to touch databases) and I ended up writing SQL code in the Asset Manager to create the databases, get the list of assets etc. But the more I used this approach the more I disliked it, and I ended up creating a wrapper class around all the SQL code, so that if I ever need to change it I only need to modify one file.

Apart from that I’ve been wrestling with wxWigets and SQLite, both of which require me to have documentation open constantly to use, so it’s slow going, but I’m happy with the way it’s progressing so far. I have made a custom control to view a list of assets, which can change between viewing as a tree structure and viewing as a list, this week I need to make it so you can retrieve the asset that is currently selected and make another control to preview texture assets.

The plan for the texture preview is to have two windows split vertically, on the left will be the image and properties of the original source texture, and on the right an image and properties of the compiled textures. The user will be able to zoom and move around both images at the same time, allowing easier comparison between the two images. The properties for the source image will be read-only, only there for reference but the properties on the compiled texture will be editable, with changes effecting the texture in real-time, so that the user can more easily determine the ideal settings for the texture.

This will require a bit of work, using as it does both images and property grids, however I am hopeful that I may get it completed within a couple of weeks, where I’ll hopefully have a video to show.

So I have decided that the engine I’m making (currently called Tyr) should have a program to condition assets before they are loaded by the engine, this is a pretty common approach for larger engines and has a number of benefits:

• You only have to load one type of file, rather than handling the range of different types that artists may produce
• You can ‘massage’ the data to make it more friendly, for example forcing the texture dimensions to be a power of two
• You can check for errors at compile time, which can be quicker than waiting for the engine to fail to load them