TGA Swap - XOR or Temporary ?
Hello all !
I’ve been experimenting with the TGA loader from Tutorial 34. Specifically, with the RED and BLUE swapping.
I have implemented Mirko Ravnikar’s XOR byte swapping into my own TGA loader, which is based on Win32 API File I/O ( instead of ANSI C like the one in Evan Pipho ’s tutorial ).
Nevertheless, the byte swapping method is the same, so there should be no speed difference between the two methods in that area.
However, on my machine ( D800, 384 MB, VC6 student version ), XOR method is actually slower than the one that uses temporary variable.
With the 24bit TGA, resolution 512*512, it takes 25 ms in average for byte swapping the entire TGA image with the XOR method. On the other hand, swapping with the temporary variable is only 14 ms in average.
I am not quite sure, but perhaps this could be because of the ''student’ version of VC6 ? I would like if someone with the real version of VC6 could verify this.
Thanks.
Pho
What is wrong with this code?
The oldest NeHe TGA loading code used to swap BGR to RGB via temporary variable, like this:
unsigned char temp = 0; // temp variable for swap
DWORD timeStart = timeGetTime(); // start time for swap
// do the swap for all image pixels
for( int byte = 0; byte < imageSize; byte+= bytesPerPixel )
{
temp = imageData[byte];
imageData[byte] = imageData[byte+2];
imageData[byte+2] = temp;
}
DWORD timeEnd = timeGetTime();
DWORD time = timeEnd – timeStart;
char buf[256]; sprintf( buf, “swap time: %d [ms]”, time );
MessageBox( hWnd, buf, “TGA Byte Swapping”, MB_OK );
Test is performed with the 24bit TGA, image resolution 512*512.
On C333, 128Mb and Riva TNT, this code yields 27 miliseconds.
On D800, 384Mb and GeForce2MX, result is 12 ms.
Several months later we got a 30% speed increase with the following code:
// do the swap for all image pixels
for( int byte = 0; byte < imageSize; byte+= bytesPerPixel )
{
imageData[byte] = imageData[byte] ^ imageData[byte+2];
imageData[byte+2]= imageData[byte] ^ imageData[byte+2];
imageData[byte] = imageData[byte] ^ imageData[byte+2];
}
However, using the code above, these are the results I get:
C333, 128Mb, RivaTNT: 46 ms
D800, 384Mb, GeForce2MX: 25 ms
Two times slower than the old method with the temporary variable.
But, all is not lost! Here is the newest code update, something like this:
// do the swap for all image pixels
for( int byte = 0; byte < imageSize; byte+= bytesPerPixel )
imageData[byte] ^= imageData[byte+2] ^= imageData[byte] ^= imageData[byte+2];
Results are:
C333, 128Mb, RivaTNT: 44 ms
D800, 384Mb, GeForce2MX:22 ms
Can anyone PLEASE explain to me any possible reasons why the code that is suppose to be faster, in reality executes slower on both of my two machines ?
The code above was compiled under student version of VC++ 6. Is it possible that the student version of VC is really messed up ?
The oldest NeHe TGA loading code used to swap BGR to RGB via temporary variable, like this:
unsigned char temp = 0; // temp variable for swap
DWORD timeStart = timeGetTime(); // start time for swap
// do the swap for all image pixels
for( int byte = 0; byte < imageSize; byte+= bytesPerPixel )
{
temp = imageData[byte];
imageData[byte] = imageData[byte+2];
imageData[byte+2] = temp;
}
DWORD timeEnd = timeGetTime();
DWORD time = timeEnd – timeStart;
char buf[256]; sprintf( buf, “swap time: %d [ms]”, time );
MessageBox( hWnd, buf, “TGA Byte Swapping”, MB_OK );
Test is performed with the 24bit TGA, image resolution 512*512.
On C333, 128Mb and Riva TNT, this code yields 27 miliseconds.
On D800, 384Mb and GeForce2MX, result is 12 ms.
Several months later we got a 30% speed increase with the following code:
// do the swap for all image pixels
for( int byte = 0; byte < imageSize; byte+= bytesPerPixel )
{
imageData[byte] = imageData[byte] ^ imageData[byte+2];
imageData[byte+2]= imageData[byte] ^ imageData[byte+2];
imageData[byte] = imageData[byte] ^ imageData[byte+2];
}
However, using the code above, these are the results I get:
C333, 128Mb, RivaTNT: 46 ms
D800, 384Mb, GeForce2MX: 25 ms
Two times slower than the old method with the temporary variable.
But, all is not lost! Here is the newest code update, something like this:
// do the swap for all image pixels
for( int byte = 0; byte < imageSize; byte+= bytesPerPixel )
imageData[byte] ^= imageData[byte+2] ^= imageData[byte] ^= imageData[byte+2];
Results are:
C333, 128Mb, RivaTNT: 44 ms
D800, 384Mb, GeForce2MX:22 ms
Can anyone PLEASE explain to me any possible reasons why the code that is suppose to be faster, in reality executes slower on both of my two machines ?
The code above was compiled under student version of VC++ 6. Is it possible that the student version of VC is really messed up ?
i don''t know ... but does the student edition let you compile normally? or are there limitation? I know the learning edition does weird things ...
therefore it may be something to do with a debug biuld, rather than a release build?
therefore it may be something to do with a debug biuld, rather than a release build?
Exactly !
Only a debug build is available in student edition.
I don''t know what other differences are there.
That is why I am interested to know what are the results on a full version of VC++6.
Is anyone with the real version of VC6 willing to try to measure the performance of byte swapping on latest TGA tutorial by using the code above? And compare it with the old byte swapping method with the temporary variable.
Thank you.
Only a debug build is available in student edition.
I don''t know what other differences are there.
That is why I am interested to know what are the results on a full version of VC++6.
Is anyone with the real version of VC6 willing to try to measure the performance of byte swapping on latest TGA tutorial by using the code above? And compare it with the old byte swapping method with the temporary variable.
Thank you.
Nither! Use GL_BGR_EXT or GL_BGRA_EXT, I use them, and every card supports it (even software OpenGL IIRC)
Celeron ][ 566 @ 850256MB PC-100 CAS2 RAMDFI PA-61 Mainboard (250MB memory bandwidth sucks, it should be 500MB)ATI Radeon 32MB DDR LEWindows 98SE
if you want to send me the source, i''ll happily test it for you ... and i can test with the learning edition as well as the full edition
mark.shaxted@btinternet.com
mark.shaxted@btinternet.com
zedzeek
Red Book: The pixel formats GL_BGR and GL_BGRA are introduced in OpenGL Version 1.2.
I believe that current Win9X implemenations are still 1.1, am I wrong ?
NitroGL
My TGA loading code does actually support BGR extension. It will fall back to R to B swap only if the extension is not supported.
Your claim that every card supports it is quite new to me. If that is true, NeHe should change Tutorial 34 to include this extension.
Shag
If you wish, I can mail you the VC project. Source code is not a secret. It is actually a part of the web site that my brother and I are currently planning and it will be free for download. It demonstrates several techiques from a space-sim game that we are currently working on, albeit in a simplified form. It is a fairly simple project that draws stars as seen from the Earth as well the Milky Way galaxy.
And here is the problem...
Because of the Milky Way textures it is quite a big download. And since I do extensive error checking all the way, the application won''t execute without the exact textures.
If you are still interested and your pipe can handle the somewhat heavy download, I''ll be glad to mail it to you.
Red Book: The pixel formats GL_BGR and GL_BGRA are introduced in OpenGL Version 1.2.
I believe that current Win9X implemenations are still 1.1, am I wrong ?
NitroGL
My TGA loading code does actually support BGR extension. It will fall back to R to B swap only if the extension is not supported.
Your claim that every card supports it is quite new to me. If that is true, NeHe should change Tutorial 34 to include this extension.
Shag
If you wish, I can mail you the VC project. Source code is not a secret. It is actually a part of the web site that my brother and I are currently planning and it will be free for download. It demonstrates several techiques from a space-sim game that we are currently working on, albeit in a simplified form. It is a fairly simple project that draws stars as seen from the Earth as well the Milky Way galaxy.
And here is the problem...
Because of the Milky Way textures it is quite a big download. And since I do extensive error checking all the way, the application won''t execute without the exact textures.
If you are still interested and your pipe can handle the somewhat heavy download, I''ll be glad to mail it to you.
July 25, 2001 12:01 AM
quote:
Original post by Pho
zedzeek
Red Book: The pixel formats GL_BGR and GL_BGRA are introduced in OpenGL Version 1.2.
I believe that current Win9X implemenations are still 1.1, am I wrong ?
I just checked the Microsoft 1.1 software OpenGL, and it does list the GL_EXT_bgra, but AFAIK ALL cards have drivers that have been updated and support those extensions, so I''d say it''s safe to use them full time.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement