Difference between revisions of "Intermediate C++ Game Programming Tutorial 10"

From Chilipedia
Jump to: navigation, search
(Channel Byte Order)
(Notes)
Line 13: Line 13:
 
The way the channels are laid out in the file are (in order of low offset to high offset) |B| |G| |R|. Now the line of code that simultaneously reads the 3 bytes of the 3 color channels, constructs a Color object, and writes it into the Surface is: <code>PutPixel( x,y,Color( file.get(),file.get(),file.get() ) );</code>. The function prototype of the Color constructor is <code>Color( unsigned char r,unsigned char g,unsigned char b )</code>, so the order here is RGB, and we would expect that our code would be messed up (the R and B channels would be swapped). But this is not the case. What gives?
 
The way the channels are laid out in the file are (in order of low offset to high offset) |B| |G| |R|. Now the line of code that simultaneously reads the 3 bytes of the 3 color channels, constructs a Color object, and writes it into the Surface is: <code>PutPixel( x,y,Color( file.get(),file.get(),file.get() ) );</code>. The function prototype of the Color constructor is <code>Color( unsigned char r,unsigned char g,unsigned char b )</code>, so the order here is RGB, and we would expect that our code would be messed up (the R and B channels would be swapped). But this is not the case. What gives?
  
Well you might (understandably) assume that our function call to the ctor evaluates the <code>get()</code> parameter expressions in the following order <code>Color( file.get()<sub>#1(G)</sub>,file.get()<sub>#2(B)</sub>,file.get()<sub>#3(R)</sub> )</code>, that is to say, the list of parameter expressions being evaluated in left-to-right order. In actuality, the compiler evaluates them in right-to-left order, i.e. <code>Color( file.get()<sub>#3(R)</sub>,file.get()<sub>#2(B)</sub>,file.get()<sub>#1(B)</sub> )</code>, and this is why our code happens to work!
+
Well you might (understandably) assume that our function call to the ctor evaluates the <code>get()</code> parameter expressions in the following order <code>Color( file.get()<sub>first(G)</sub>,file.get()<sub>second(B)</sub>,file.get()<sub>third(R)</sub> )</code>, that is to say, the list of parameter expressions being evaluated in left-to-right order. In actuality, the compiler evaluates them in right-to-left order, i.e. <code>Color( file.get()<sub>third(R)</sub>,file.get()<sub>second(B)</sub>,file.get()<sub>first(B)</sub> )</code>, and this is why our code happens to work!
  
 
Even stranger is the fact that <big>the C++ standard does not specify the order in which the parameter expressions are evaluated!</big> So it is possible that a different compiler could generate code that gives a different permutation of the color channels. In actuality, we can expect most compilers to do it right-to-left because of the way parameters will be pushed onto the stack (which ''is'' mandated), but still, it is terrible practice to rely on this unspecified behavior to always be the way we wish it to be.
 
Even stranger is the fact that <big>the C++ standard does not specify the order in which the parameter expressions are evaluated!</big> So it is possible that a different compiler could generate code that gives a different permutation of the color channels. In actuality, we can expect most compilers to do it right-to-left because of the way parameters will be pushed onto the stack (which ''is'' mandated), but still, it is terrible practice to rely on this unspecified behavior to always be the way we wish it to be.

Revision as of 12:59, 13 October 2017

The promised day has come. We're finally going to be loading images from bitmap files into memory and drawing them as sprites on the screen. This is where all that stuff we've been learning--data types, pointers, memory management, file access, etc.--is going to pay off bigtime. Also, get fukt massive PutPixel sprite functions; die in a garbage fire.

Topics Covered

  • Surface class for storing image data in memory
  • Parsing Windows bitmap file headers and loading pixel data
  • Calculating padding
  • Drawing sprites (pixel blocks) from a Surface to the screen

Notes

Channel Byte Order

There is a rather large issue with how the color channels are loaded from the bitmap file, but due to a freak of coincidence, the code works regardless. Still, we must address this buttfuckery.

The way the channels are laid out in the file are (in order of low offset to high offset) |B| |G| |R|. Now the line of code that simultaneously reads the 3 bytes of the 3 color channels, constructs a Color object, and writes it into the Surface is: PutPixel( x,y,Color( file.get(),file.get(),file.get() ) );. The function prototype of the Color constructor is Color( unsigned char r,unsigned char g,unsigned char b ), so the order here is RGB, and we would expect that our code would be messed up (the R and B channels would be swapped). But this is not the case. What gives?

Well you might (understandably) assume that our function call to the ctor evaluates the get() parameter expressions in the following order Color( file.get()first(G),file.get()second(B),file.get()third(R) ), that is to say, the list of parameter expressions being evaluated in left-to-right order. In actuality, the compiler evaluates them in right-to-left order, i.e. Color( file.get()third(R),file.get()second(B),file.get()first(B) ), and this is why our code happens to work!

Even stranger is the fact that the C++ standard does not specify the order in which the parameter expressions are evaluated! So it is possible that a different compiler could generate code that gives a different permutation of the color channels. In actuality, we can expect most compilers to do it right-to-left because of the way parameters will be pushed onto the stack (which is mandated), but still, it is terrible practice to rely on this unspecified behavior to always be the way we wish it to be.

The following code fixes this problem. It will be applied to the Sprite repo and the Twin repo on GitHub.

const unsigned char b = file.get();
const unsigned char g = file.get();
const unsigned char r = file.get();
PutPixel( x,y,{ r,g,b } );

Self Assignment

We definitely should be checking for self assignment (mySurf = mySurf;) in the assignment operator for Surface. See the Errata of Intermediate 6 for more details.

Video Timestamp Index

Tutorial 10

Source Code

Sprite Repo

Download Materials

Homework

The homework is to improve the bitmap loading routine to support 32-bit RGB format and to support bitmaps with reverse row order.

See also