TGA file format question
Author
ok I can open the TA file format but the colors and messed up. I know that the colors in the uncompressed TGA are stored as BGR and not RGB so i have this right fix it, or so i thought but colors are still messed up. what is wrond with this:
for( GLuint i = 0; i < ( int )image_size; i += bytes_per_pixel )
{
// stores the blue color bit
GLuint temp = _image_data;
// switches the blue color bit with the red color bit
_image_data = _image_data;
// put the sotred blue color bits in the thrid spot where it should be
_image_data = temp;
}
I know that loops through every pixel but inside the loop, is everything ok?
That's the code Ive got in my LoadTexture function. Perhaps the error is elsewhere?
Check the format being supplied to glTexImage2D (Is that what your using yeah?)
(Remeber its GL_RGB if 24bpp else GL_RGBA for 32bpp)
Check the format being supplied to glTexImage2D (Is that what your using yeah?)
(Remeber its GL_RGB if 24bpp else GL_RGBA for 32bpp)
It supposed to be BGR.
this will do it
_image_data ^= _image_data[i+2] =^ image_data ^= image_data[i+2];
that'll switch it to RGBA.
think of it this way.
A XOR B = AXORB
AXORB XOR A = B
AXORB XOR B = A;
make sure you test your bytes per pixel before you submit to gl.
this will do it
_image_data ^= _image_data[i+2] =^ image_data ^= image_data[i+2];
that'll switch it to RGBA.
think of it this way.
A XOR B = AXORB
AXORB XOR A = B
AXORB XOR B = A;
make sure you test your bytes per pixel before you submit to gl.
That XOR trick strikes me as premature optimisation to be honest. It'd be better to just swap manually, or use std::swap, and keep your code readable, than to do fancy tricks under the false assumption that it'll make your code faster.
To the OP, have you tried dumping your image data out as a RAW file once you've loaded it, and viewing it in an image program? Load in a 24bit TGA, and dump the contents of _image_data to a file with the extension .RAW. If the file looks fine in a program capable of using RAW images, then it means your texture is loading fine, but the code that displays it isn't.
I used this trick when testing my TGA loader, and it was a big help.
To the OP, have you tried dumping your image data out as a RAW file once you've loaded it, and viewing it in an image program? Load in a 24bit TGA, and dump the contents of _image_data to a file with the extension .RAW. If the file looks fine in a program capable of using RAW images, then it means your texture is loading fine, but the code that displays it isn't.
I used this trick when testing my TGA loader, and it was a big help.
It's not that much of an optimization. Not really a fancy trick either. Its just some basic boolean operations.
Then there's no point in using it over manually swapping or using std::swap, all it does is make your code harder to read and debug, for someone unfamiliar with the XOR trick.
If you find that the swapping is a bottleneck, then by all means try the xor trick, but otherwise there's no point.
If you find that the swapping is a bottleneck, then by all means try the xor trick, but otherwise there's no point.
its not a trick o.O its basic boolean algebra.
How is it that much harder to read?
its just a few ^='s, thats like saying
i[0] += i[2] += i[0] += i[2]; is harder to read.
in the end its a matter of preference.
I only suggested it in this case because its very useful for byte swaping.
but you can use the temporary variable method.
Just stick with what you're comfortable with.
How is it that much harder to read?
its just a few ^='s, thats like saying
i[0] += i[2] += i[0] += i[2]; is harder to read.
in the end its a matter of preference.
I only suggested it in this case because its very useful for byte swaping.
but you can use the temporary variable method.
Just stick with what you're comfortable with.
Nothing in the c++ standard prevents a std library provider from providing a template specialization for std::swap on unsigned chars.
I'd be very suprised if the XOR trick outperforms std::swap on any decent optimizing compiler.
I'd be very suprised if the XOR trick outperforms std::swap on any decent optimizing compiler.
XOR won't outperform std::swap on many cases which is merly a templated version of the temporary variable solution.
Like if it were doubles then XOR would be slower. But if using ints or chars XOR tends to be slightly faster.
I don't really know how much further swap can be optimized.
Like if it were doubles then XOR would be slower. But if using ints or chars XOR tends to be slightly faster.
I don't really know how much further swap can be optimized.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
