backslash Wrote:No you're not - RGBA with unsigned bytes is 4 separate single bytes, which happens to be the same size as an unsigned int on many systems, but you are making the very mistake you are telling us all to avoid. I like Jake's solution.

On the other hand 565 RGB is what ? 5 bites of red , 6 bits of green and 5 bits or blue ? ... or more is more likely to be referred as unsigned short ?

Perhaps , but once you end up writing code trying to manipulate individual bits ( as you would if you were to attempt to update the buffer) you would end up casting it back and forth into unsigned short or unsigned int depending on how optimized you want your code to be and RGB_565_BYTES_PER_PIXEL would be of no use at all.

warmi Wrote:Perhaps , but once you end up writing code trying to manipulate individual bits ( as you would if you were to attempt to update the buffer) you would end up casting it back and forth into unsigned short or unsigned int depending on how optimized you want your code to be and RGB_565_BYTES_PER_PIXEL would be of no use at all.

warmi Wrote:In fact , the first thing a programmer will think when looking at your code is something like ... hmm, what is RGB_565_BYTES_PER_PIXEL ... it must be unsigned short since he is casting to it.

That is not at all what an experienced programmer will think. What they'll think is, first of all, "I'm working with unsigned short data", and then "ooh, nice, I'm glad somebody actually thought to mention this is specifically 565 data we're working with." The RGB_565_BYTES_PER_PIXEL has absolutely nothing to do with the data type itself, only that the constant we're using to calculate how much memory we need to calculate is described verbosely, instead of just width * height * 2, or width * height * sizeof(unsigned short).