(red<<11) + (green<<5) + blue and ((blue%32) + ((green%64) << 6) + ((red%32) << 11)) are the same thing (in 16-bit, 5.6.5 mode). its a fact. my question is, why are they the same, and what does the % do? Edited by - Zipster on 3/19/00 1:55:36 AM

I''m not sure cause i never used those macros (have own fucntion to decide how many bits to shift for each color)

number%32 returns a number from 0 to 31, I think the second macro normalizes the color cvalue from 0,31 for red 0,64 for green (since the human eye take green more than other colors) and 0,231 for blue


well i can be totalyy wrong here but i think it is cause of that

The % sign is the modulus operator. Basically, it's a way to tell the remainder of a number divided by another number. (so, if you were to divide 11 by 10, 11%10 would equal 1 (11/10 gives 1 with a remainder of 1), as would 21%10 (21/10 gives 2 with a remainder of 1))

In this case, you use it to make sure that the number falls within a certain range. They want to verify that blue is a number between 0 and 31, green is between 0 and 63, and red is between 0 and 31. If these were above their ranges, the added number could cause some serious issues with the final number sent to blit the pixel. Say that blue was set to 50. Since the blue component only takes up 5 bits (0 thru 31), the remainder of the 50 (18) would get added to the green component.

Frankly, I would use the bitwise AND operator to make sure the number is 0 thru x. The following formula would work (and would be slightly faster than the % operator due to the math performed to get the modulus):

((blue & 31) + ((green & 63) << 6) + ((red & 31) << 11))

Hope this makes sense. It's late

-Chris


---<<>>---
Chris Rouillard
Software Engineer
crouilla@hotmail.com

Edited by - crouilla on 3/19/00 2:24:34 AM

um, you''re both completely wrong. i did the math with a few random RGB values, and they are totally different equations if % is used as a modulus. take 64, 12, and 42 as an RGB value. the first equation evaluates to 131,498. the second equation evaluate to 64. % isn''t modulus, its something different.

and towards Akura, this doesn''t generate a random number either. otherwise, how could we control color?

Hmm... that''s funny. Are you sure you compiled it correctly before saying that we''re both completely wrong?

Simple program -- simple output:

void main()
{
cout << 33 % 32 << endl;
cout << 65 % 32 << endl;
cout << 123 % 32 << endl;
}

Outputs:

1
1
27

Proof:

33/32 = 1 with a remainder of 1
65/32 = 2 with a remainder of 1
123/32 = 3 with a remainder of 27

From Microsoft VC++ help:

Modulus Operator: %
The result of the modulus operator (%) is the remainder when the first operand is divided by the second.

Example

In the following example, the modulus operator is used to determine if the numeric value 4 evenly divides into nCenturyYear. If the remainder is zero, the nCenturyYear must be a leap year, so the LeapYearFunction() is executed.

// Example of the modulus operator
int nCentury;

if ((nCenturyYear % 4) == 0) {
LeapYearFunction();
}

I think that since I''ve been programming C for about 10 years now that I would know what a modulus operator was (and, no, it hasn''t changed with the advent of C++, unless you overloaded the operator)

-Chris

---<<>>---
Chris Rouillard
Software Engineer
crouilla@hotmail.com

% is definately modulus. For example to get a random number between 0 and 255:

#include

int nNum = rand()%256

as rand givs numbers way higher than 256 this works (rand outputs into 5 digit numbers). hat it does id divide the value returned by rand() by 256 and then give the number that remins (the remainder) that will not go once more into 256. I think that''s an explanation, but I dunno

Hargle

and why do I always foget that < signs don''t show up...that is the < sign
goddam it!!!
/
\
that kinda shape but smaller and its friend the greater than operator damn them hiding!

Hargle

I never said anything about random

quote: Original post by Zipster

(red<<11) + (green<<5) + blue and
((blue%32) + ((green%64) << 6) + ((red%32) << 11)) are the same thing (in 16-bit, 5.6.5 mode). its a fact.

my question is, why are they the same, and what does the % do?

Edited by - Zipster on 3/19/00 1:55:36 AM

No, they''re only the same thing if and only if
blue is from 0 to 31
green is from 0 to 63
and red is from 0 to 31

Without the % you can get funky overlaps in color values.
ex:
blue 63 111111 binary
green 16 010000 binary

Without the % :
red << 11 + green << 5 + blue =
00000010 00111111 binary

With the % :
(red % 32) + (green % 64) + (blue % 32) =
00000010 00011111 binary

You can see that in the first example blue bits started to invade green bit territory.

To Akura:
you said, i quote, "number%32 returns a number from 0 to 31 ". that implies a random number.
The % can''t mean modulus in this situation!!! i tried random numbers between 0 and 255 for RGB values, and both equations consistantly churn out different results .
For example, lets use RGB(234,76,134). appropiate values, yes. lets plug em'' in:
(234 << 11) + (76 << 5) + 134
doin the math, we get 481,798
((134%32) + ((76%64) << 6) + ((234%32) << 11))
boils down to:
(4 + (1 << 6)) + (7 << 11)
we get 14,404 .
AND I KNOW 481,798 is NOT EQUAL TO 14,404!!!!
IN THIS SITUATION, % DOES NOT MEAN MODULUS!!
I just proved that to you. if you think my calculations are wrong, do ''em yourself and see!!!