Disappointed in that, I put my head down and got to work.

While working, I realized I could combine both methods, and get the benefit of both.

And eventually finished.

So the Texture Pool is done, but it is late, so I’d rather call it a night. I may revisit earlier post, since it does have some meaningful information in it.

As for a Sunday tool, we’ll see. I gotta read over my notes and think a bit about how badly I want the image slicer stuff, or if I should get on to the slightly hacky screen builder. Hmm..

Toodles!

So I need a Texture Pool. In other words, I want a nice way to say “hey, load blah.png”, and it’ll use it’s brains to know that I already loaded “blah.png”, and return me the same copy. Pretty straight forward stuff.

This Texture Pool is a piece I’m adding to my graphics library. Said library is designed to wrap multiple graphics API’s. Currently it wraps OpenGL (1.5) and OpenGL ES (1.1), but it also has a slightly out of date software renderer too (lacking texture support, but does geometry and transformations).

The Texture Pool itself I’d like to eventually support several formats. Currently it supports a hybrid format of mine, LZMA’d Power VR (PVR) files. The way it’s structured, it’s easy enough for me to support ZLIB, BZIP, or RAW PVR files as well, I just don’t currently. And while I don’t yet support them, I have stubs in place for PNG and DDS files.

I have some other wild goals for the Texture Pool down the line. Right now, one of my main target platforms requires square power-of-two textures. So I’d like to build a tool for combining multiple smaller images in to a single texture atlas. I’d also like a way to automatically fatten up a PNG image file, yet still somehow remember the original dimensions. This slicing information I’d like to be known by the Texture Pool, so I can draw centered or aligned texture elements with just a call, instead of having to build geometry or remember dimensions.

My solution to both is a custom file format, vaguely like an archive format. As an added bonus, I want it to be able to support storing multiple images in the same file. But the important point is to create this “many to one” relationship, where I have a single texture and some way to say it contains many elements. I’m leaning towards throwing together a text based format and tool to generate a sliced file, so I can start using this right away.

Alas, that’s a tomorrow issue.

Today, we’re building a Texture Pool. After some breakfast, we’ll do it.