16Bit video graphics, is this normal -[RESOLVED]-

I didn't think this is worthy of the Graphics section because its mainly me going off on one but I totally don't agree with this:

Code:

---

_RGB565(255,511,255) // White

---

Does anyone know if its normal for 16bit (565 mode) to have the color white as this?

I totally disagree, any thoughts?

(What have I opened this up to posting here, I know I'll get some smart arse answers but I welcome them :D.)

Uhm.

5 bits = 32
6 bits = 64

So it'd be... 31(11111) | 63(111111) | 31(11111)

I guess?

Yeah that would have been my thoughts too, this is the macro that comes on the engine I had to use:

Code:

---

#define _RGB565(r,g,b)  ((((b>>3)%32)) + (((g>>4)%64)<<6) + (((r>>3)%32)<<11))

---

But it took me ages to find that 255,511,255 makes it white, I was trying all sorts :(.

Did it take you ages...:D:D:D::D


2^5 = 256
2^6 = 512


...:D

No ages there...

BTW it is one of the normal screen resolutions that DX uses....I also think it has one that uses the last bit as "Alpha" as I said earlier.-..but I have to look up that on my other PC tomorrow...

No no no, 555mode just has one bit left over, I don't think it gets used at all.

As for it taking me ages it did, I was mainly trying thingsing in the 255 area in the exam. And when I shoed you it earlier I only then decided to try higher numbers. Its totally messed up :( I best not loose marks for it or I'll have to kick some ass at Uni :D.

I win.....I just checked it out in my DX Caps viewer. And even my old laptop has the

A1 R5 G5 B5

format...it uses one bit for alpha...;)


it is also one format that is not using it at all called:

X1 R5 G5 B5

But I was right...one more point to me..:D


So when do you want me to take over the mod mod mod job in the game section....;)

http://www.vbforums.com/attachment.p...postid=1699806

lol, you have a lot more point you still gotta get yet :D. I admit my defeate here but I won in the C++ thingy ;).

I actually hate 16bit color to be honest and I'm really not happy that this year they made us use it :(. 32bit is a whole lot nicer ;).

Quote:

---

Originally posted by Electroman
lol, you have a lot more point you still gotta get yet :D. I admit my defeate here but I won in the C++ thingy ;).

I actually hate 16bit color to be honest and I'm really not happy that this year they made us use it :(. 32bit is a whole lot nicer ;).

---

No you did not win that one either...you said that the "" was the error, and I said NO...and I was right..and found the actual error...2-0 to me....YOU ARE OUT buddy,..:D

Quote:

---

Posted by NoteMe
No you did not win that one either...you said that the "" was the error, and I said NO...and I was right..and found the actual error...2-0 to me....YOU ARE OUT buddy,..:D

---

:eek2: Was I right or not? it wasn't the problem but I was right :p. As for this one I don't believe the Alpha thingy had anything to do with my problem so its either 0-0 or 1-1 (not counting my other thousand or so other wins :D.)

Quote:

---

Originally posted by NoteMe
Did it take you ages...:D:D:D::D


2^5 = 256
2^6 = 512


...:D

No ages there...

BTW it is one of the normal screen resolutions that DX uses....I also think it has one that uses the last bit as "Alpha" as I said earlier.-..but I have to look up that on my other PC tomorrow...

---

Are you fuggin drunk?

2^5 = 32
2^6 = 64

Silly mouse, math is for smart people. :afrog:

I can explain this...

#define _RGB565(r,g,b) ((((b>>3)%32)) + (((g>>4)%64)<<6) + (((r>>3)%32)<<11))

That seems backwards.... the g would be divided by 16, the r and b are divied by 8.... it seems that'd be 545... ***.

Cuz say you give it 8 bits... b to 5... g to 4... r to 5....

But uhm... if you're passing a larger g... say an int(16 bits) then there would be 12 left... Yea.. that make sense! 65536 / 16 / 64 = 64. Tada There you go, 565, byte, int(2 bytes), byte. Would be the passable args.

So white would seem to be 255,65535,255....

Or I don't know what % does....

ok...i don't have the time to "explain" (at least have a go) this now...but let me try...:D...my exam is comming up here..:D


#define _RGB565(r,g,b) ((((b>>3)%32)) + (((g>>4)%64)<<6) + (((r>>3)%32)<<11))


in this line you are doing it backwards as you say.


We want a 16bit value

00000000 00000000

First it calculates the (b)

You are passing it a int (2 bytes...at least I hope)

if you write 255 as we did:

00000000 11111111

then right shift 3

00000000 00011111 (= 31)

then...ehhh....% is modulus??? isn't it?

but since 31 is under 32 you still have 31

then you have used the lover bits.

Then you calculate the green bits:

511 in binary 16 bits are
00000001 11111111

then right shift 3
00000000 00111111 (=63)

then use modulus with 64, but since 63 is under 64 you still have 63

then right shift 6
00000111 11100000

then the red bit. You write 255
00000000 11111111

right shift 3
00000000 00011111 (=31)

Then modulus 32, and you still have 31

then left shift 11:
11111000 00000000



Then add the b + g + r and you have

b: 11111000 00000000
g: 00000111 11100000
r: 00000000 00011111
AND
-------------------------------
11111111 11111111


Whitch is white....;)


I am sooo goooood

so if you write (255, 511, 211) you have white...;)

And PS...I was not drunk yesterday....but I wish I was that so that could have explained my bad binary counting....:D:D:D

BTW if I am right about this....then there will be more then 255,511,255 that will make white. But if you are sure that you are never writing bigger numbers then this, then the engine would work faster without the % part in your define line....;)

And when did you say I could take over your job....:D:D:


Just kidding with you...:D

Uhm... Hello? The g is bitshifted 4 not 3!

Left-to-right bitshift 4 is = to / 16. 2*2*2*2

So 512/16 = 31 ish... mod 64... still 31 ish!

That's ~half the 6 bit possible value of 64.

So you'd atleast need 1024... / 16 = 64, but mod that by 64, and you get zero. So 255,1023,255 would make white(and be the minimum value). Unless it really is R5G5B5 A1....

I say you get new code!

I'm so gonna kick this lectures ass, its part of his Dx2 (maybe 3) graphics engine. I have already correct some of his code for him on hiding the mouse, he was just using SetCursor(NULL); in the game loop and he was saying he didn't have a clue how to keep it hidden. I simply told him your meant to put it in when you get the message: WM_SETCURSOR.

Anyway back to this, what would you say the macro should be then? Cos as I've said before I totally hate 16bit graphics and thats mainly because the fuss you have to go through to work out colors (makes pixel perfect collisions a real hassle).

My converting code....(PS: why did you post this in the chit chat section.....I barely have the effort to post this you know...:D

Code:

---

DWORD ColorRefToR5G6B5 (COLORREF crSource){
  DWORD dwRed = GetRValue(crSource);
  DWORD dwGreen = GetGValue(crSource);
  DWORD dwBlue = GetBValue(crSource);

  //shift values to the left
  dwRed >>= 3;  //8-5=3
  dwGreen >>= 2; //8-6=2
  dwBlue >>= 3; //8-5=3

    //shift values to the right
  dwRed <<= 11; //5+6=11
  dwGreen <<= 5;

    Recombine components
    DWORD dwColor = dwRed | dwGreen | |dwBlue;

    //return the color

  return (dwColor);

}



// Taken from the book 2D in D3D.

---

I'd thought that just before, this seems to have turned out to be a good thread. When I posted it I was only wanting to rant on about how stupid the macro was to start with.

BTW what values does your function take? it is sensible yes?

And from that I get the general code for color format changes:

Code:

---

DWORD ConvertFromColorRef(COLORREF crSource, DWORD dwRBits, DWORD dwGBits, DWORD dwBBits){

  //extract color components
  DWORD dwRed = GetRValue(crSource);
  DWORD dwGreen = GetGValue(crSource);
  DWORD dwBlue = GetBValue(crSource);

  //shift values to the left
  dwRed >>= (8 - dwRBits);
  dwGreen >>= (8 - dwGBits);
  dwBlue >>= (8 - dwBBits);
 
  //shift values to the right
  dwRed <<= (dwGbits + dwBBits);
  dwGreen <<= (dwBBits);

  //recombine components
  DWORD dwColor = dwRed | dwGreen | dwBlue;

  return (dwColor);

}

---

Hope I didn't screw up this code....I didn't test it...just wrote it in here...:D

Quote:

---

Originally posted by Electroman
I'd thought that just before, this seems to have turned out to be a good thread. When I posted it I was only wanting to rant on about how stupid the macro was to start with.

BTW what ales does your function take? it is sensible yes?

---

What it take?? A COLORREF??....don't get you...and yeah I took it from a book...but I wrote it off, so I hope I didn't screw it up. The other one is a bit more genral...hop I didn't miss anything trying to make it genral for all display formats.

BTW can't you ask to get this thread moved...and then you can delete all the ranting posts like this one?

Yeah I'll ask for it to be moved ;).

Mind I don't think I've used Colorref's before, your forgetting I'm very new to the whole C++ part of stuff ;).

MSDN:

Quote:

---

COLORREF
The COLORREF value is a 32-bit value used to specify an RGB color.

Remarks
When specifying an explicit RGB color, the COLORREF value has the following hexadecimal form:

0x00bbggrr

The low-order byte contains a value for the relative intensity of red; the second byte contains a value for green; and the third byte contains a value for blue. The high-order byte must be zero. The maximum value for a single byte is 0xFF.

---

Added by me:

Quote:

---

The format in pseudo bits are something like

00000000 RRRRRRRR GGGGGGGG BBBBBBBB

The 0's are unused bits.

GetRValue and GetBValue and GetGValue is three macros.

---

Not sure if this is usefull at all. But it at least converts something..:D..

Let me look at your code again.

Ohhh...I did a mistake.....

+ is not adding bitwice (sp?)...not sure what it does actually...but the | does it.

So if you write:

Code:

---

#define _RGB565(r,g,b)  ((((b>>3)%32)) | (((g>>3)%64)<<6) | (((r>>3)%32)<<11))

---

Then my explenation with bitshift right 3 works..;)

Does this mean your code above is right then ;)

Quote:

---

Originally posted by Electroman
Does this mean your code above is right then ;)

---

What code? The code from the book?...I havn't testet that....but what a sec. I have a screen shot for you...

Neither my:

Code:

---

#define _RGB565(r,g,b)  ((((b>>3)%32)) | (((g>>3)%64)<<6) | (((r>>3)%32)<<11))

---

or his:

Code:

---

#define _RGB565(r,g,b)  ((((b>>3)%32)) + (((g>>4)%64)<<6) + (((r>>3)%32)<<11))

---

is making 100% white....look at the picture. Not sure if this is an issue becuase the screenresolution is not 16 bit..

http://vbforums.com/attachment.php?s=&postid=1700258

Tested it now in 16Bit mode, and still not white...

Might have to have a look and see if I can work out a macro for it....

Addition would simulate OR.