Texture file formats & saving textures

paradox/vivid

Introduction

Hi all! This tutorial is a continuation of my one about texture generation. It isn't about basic file i/o it has some more "advanced" features.

Coding a texture editor

Firstly, do NOT code your editor for DOS, code it for winDOwS or Linux, you'll get a much nicer interface when you're finished. I am currently coding one in Visual Basic, BUT to show you the utter crapness of a DOS based one, I have included (source+exe) of my one, ugh, it's even buggy!

Texture Formats

Firstly, I have not included any of my generated textures to load, the reason being that I'm not finished upgrading my generator and it's a bit awkward to include them, sorry. To encode texture we assign each filter a number, and write that number to the texture file to illustrate what filter to expect in the re-generation routine. Of course, we must also specify the arguments.

The number indicating which filter should be as small as possible, approximate it to the nearest power of two above it, and write that number of bits to represent it. E.g. if we had 14 filters we'd write 4 bits because 2^4 = 16 and 16 is the smallest power of two bigger than 14. Basically, save space.

Also, use the appropriate types of argument, if an argument only needs to be a byte, use byte not an int! If it needs to be a 2 byte int, use a 2 byte int, not a four byte int! Basically, save space.

If you don't follow the above directions you'll get crap sizes (200 bytes) for textures, they should be about 100 bytes. If you do create textures this small to have 30 in an intro would only take 3000 bytes.

Now, you may find that your textures are large, larger than 100 bytes. If so, it may be because they are very complex, what we mean by complex is "complex with respect to our texture generator". All our textures can be represented by 256x256x24bpp images, and there is no such complexity issue associated.

If your textures are like that, look for the redundancy by hand, are some filters too general? Or, are some used very often and some used sparingly, assign the more frequently used ones more bits (even in a static way). Also, if lots of the time one filter is proceeded by another (like it is its context), create a new filter which is the two put together, thus saving space. For example, smooth tends to follow the random filter.

And lastly, our texture generation process is like the reverse of fractal image compression, the idea behind that is to save images by lists of instructions rather than pixel data (and this is done by looking for self similarity in the images). So, given an image, fractal image compression generates the instruction list. We take an instruction list, and make an image from it, and we design the instruction list, the question is, if we developed enough instructions could we do something similar to fractal image compression? Well, probably not, but think about it anyway.

Conclusion

I hope you learned something here. bye.

--para