This should, in theory at least, be a pretty simple library to get up and running as alot of the code I'll be stea.. errm, reusing already exists which is just what any library writer likes to see [grin]
The other reason this should be easy is because its designed todo one thing and one thing only; load textures.
Yes, thats it folks, no fancy filtering, flipping or otherwise maipulating the images, its just here to load and decode the images into something useable and present you with an interface to work with them.
Currently the plan is to get code in place to load
- BMP
- JPG
- PNG
- DDS
- TGA
as these are the most common texture formats I've seen (DDS being of pertcular intrest to me).
However, as I'm not blind to the idea of things improving I plan to make it simple to extend. Some people out there might already be getting shivers at this point as 'easy to expand' normally = bloated, however I'll be trying my best to avoid allowing things to bloat out of control.
Another key factor is to be able to deal with images containing multiple images, such as cubemaps and mipmaps (and indeed, both at once) as well as 3D images. The simplest way to deal with with this seems to be query functions to a class, however the idea of a struct with const members is also appealing.
Interface wise, everything is going live in a namespace, currently "GTL" or "GameTextureLoader" (the later could be aliased to "GTL" by the end user).
If I go for the class based system then it will have a group of free functions to load the texture which return a pointer to an object. This object (Image) will present an interface to allow you to retrive infomation about the texture loaded as well as gain access to the texture data.
If the struct method is decided apon then the infomation will be directly accessable, the only thing which would be required would be a couple of free functions to extract the texture data from the object correctly (adapting for mipmap levels and various texture formats).
Right now, I'm not sure which option is the better, so I'll have to get some feedback on that part.
I've done some primary thinking about the Image class;
Image{ Image(); ~Image(); int getMipMapsPerImage(); int getNumOfImages(); int getWidth(); int getHeight(); int getDepth(); int getColourDepth(); TYPE getFormat(); TYPE *getData(int image,int mipmap); TYPE *operator[](int mipmap); TYPE *operator()(int image,mipmap);}I've used TYPE where I havent decided on the return type as yet. The reason I've considered 3 access methods is to take an STL like look at things, where getData() is bounds checked and can throw an exception if you try to access an invalid image or mipmap level and the other two allow unchecked access to data.
However, I might not use them.
I've also just considered the idea of using iterators to step between images and then use a proxy object to get the correct mipmap level, however as I dont see there being more than 6 images at most I'm not sure how much of a point there would be to it.
The struct would hold much the same data as above, just in a constant format and require a function to perform proper image/mipmap extraction.
struct Image{ const int height,width,depth,colourdepth; const TYPE format; const int numImages,numMipMaps; TYPE const * const data;}I'll work on more of the specifics once I get a chance to bounce this off a few people and see what they think.
(edit: fixed up consts a bit.. I think I've got that last const right, I need to brush up on my const correctness a bit I think)
It's what I use for loading textures into an OpenGL context created by SDL, and I have been very happy with it so far. I suspect it could be fairly easily modified to not need SDL.