• entries
455
639
• views
424520

# GTL Part 1 : And So It Begins...

203 views

After deciding that all the current solutions for texture loaders are... poo.. to say the least in a fit of depression inspire scribblings I've started work on what is currently being refered to as The Game Texture Loader (GTL).

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)

If you were feeling lazy you could always modify SDL_Image to have it load a texture in whatever format you need (it loads into a SDL_Surface*, but you could change that). It's licensed under the LGPL though, which might or might not be a good thing for you. It's also written in C, which might not be what you're looking for.

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.

While I appricate the idea SDL related stuff is ruled out simply because it is LGPL, I'll be releasing this code under the zlib licence.

Plus, interface, style and C++ issues aside, I'm not sure how compatible SDL_Image is going to be with what I'm going to need, specifically when it comes to DDS images.

As I belive said below, I'm currently using Corona, and I like it but I just dont feel like trying to fix up a code base, more so when I need less than it supplies anyways and I'll be changing fundimental aspects of the API, better to create a new one imo.

I figured it probably wouldn't be an option, but I thought I'd throw the idea out there just in case you wanted to only have to extend it by writing a DDS loader for it.

Taking out all the SDL related stuff to create your own library out of it might also be more work than I realize - I haven't dug through the SDL_Image code.

Quote:
 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.
This must go under your lazy programmers are good theory. [grin]
Quote:
 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.
This sounds helpful. I did some GL stuff a few weeks ago for the first time and had a hard time finding something that could load all of these formats. DDS would be very nice. Keep up the good work. [smile]

I haven't progressed to this stage yet, but be aware that DDS files are significantly different beasts when compared to the others. You don't want to decode them yourself if your graphics API can take them immediately. But you sort of mentioned this in your last entry so I'll be quiet now ;)

Another point, you mention it won't flip textures. I assume it will load flipped TGA files correctly though?

Yeah, the plan is to have all textures in a normalised direction, so top for BMP is the top for PNG, TGA and any other format, so you can seemlessly swap from one type to another without having to worry about changing texture coords or flipping the image data.

Do eeeet. I'd use it.

## Create an account

Register a new account