Page 1 of 1

Determing a pixel's RGB components with GAPI

PostPosted: May 23, 2001 @ 4:08pm
by Frank W. Zammetti

Re: Determing a pixel's RGB components with GAPI

PostPosted: May 23, 2001 @ 4:30pm
by Dan East
That depends on the type of RGB encoding (555, 565, 888 ). Check the ffFormat member of the the display properties to determine the actual encoding. AFAIK, all devices use 565 at this time. This is off the top of my head, so it may need tweaking:<br>[pre]<br>//RGB 565 -> 24 bit RGB<br>int red=(pixelColor&0xf800)>>8;<br>int green=(pixelColor&0x7e0)>>3;<br>int blue=pixelColor&0x001f<<3;<br>[/pre]<br>Note that with 565 encoding green can have twice as many shades as red or blue.<br><br>Dan East<br><br>Last modification: Dan East - 05/23/01 at 13:30:59

Re: Determing a pixel's RGB components with GAPI

PostPosted: May 23, 2001 @ 4:52pm
by Digby
Back in the early DDraw days, drivers would be notorious for reporting the wrong pixel format for surfaces.  What we'd do is draw a red, green, and blue pixel on the screen using GDI's SetPixel(), then go read what was actually written to video memory using DDraw.  That way you absolutely knew which bits were being set for each color component.  <br><br>You shouldn't have to do that with the PocketPC though, since the display modes don't change and you can't swap out the video display hardware.<br>

Re: Determing a pixel's RGB components with GAPI

PostPosted: May 23, 2001 @ 4:54pm
by suchiaruzu

Re: Determing a pixel's RGB components with GAPI

PostPosted: May 23, 2001 @ 11:37pm
by Frank W. Zammetti

Re: Determing a pixel's RGB components with GAPI

PostPosted: May 24, 2001 @ 3:51am
by Malmer

Re: Determing a pixel's RGB components with GAPI

PostPosted: May 24, 2001 @ 8:58am
by Dan East
To expand on what Fredrik said, you are starting with colors that are 8 bits per color component. Those are converted to 5 bits for red and blue, and 6 bits for green. So you lose 3 bits of information from red and blue and 2 bits from green.  3 bits is equal to 8 decimal, while 2 bits is 4 decimal. So red and green may be equal to, or up to 8 less than, your original value, while green may be up to 4 less than the original color value.<br><br>Original 8 bit Red in binary:<br>RRRRRRRR<br>After converted to / from 5 bits:<br>RRRRR000<br>The lowest three bits will always be zero, hence your lost precision. If it so happened that in the original value the lowest 3 bits were already zero, then there was no information to lose, so the result will match. In the values you gave, 200 matched. 200 in binary is 11001000. Clear as mud? :)<br><br>Dan East<br><br>Last modification: Dan East - 05/24/01 at 05:58:29

Re: Determing a pixel's RGB components with GAPI

PostPosted: May 24, 2001 @ 9:12am
by Frank W. Zammetti
Grr... It IS clear as mud, it's just that mud sucks!<br><br>I guess the work-around is to pre-decrease the values when I plot them.  In other words, zero out the lowest three bits of R and B and two bits of G and use those as my color components.  Then when I read a pixel from the VFP, I would expect to get the same values I put there then.  <br><br>Fortunately, in my application I think it's not a big deal because I was actually writing a function to dim a portion of the screen, so basically this means that my colors will start out dimmed slightly already.  I was expecting this to lead to a sprite collision detection algorithm, so I would have had to have dealt with this anyway.<br><br>Does the pre-decreasing idea sound right though?  I'll test it later, but it seems to make sense at the moment (it IS 9 in the morning though, way too early for MY brain!)  Thanks again guys, you've all been a great help!

Re: Determing a pixel's RGB components with GAPI

PostPosted: May 24, 2001 @ 9:27am
by Dan East
That sounds good. If you pre-translate all your bitmaps to the RGB encoding used by the device then it will save a lot of processor time when you blit the screen out. The disadvantage is that some processing, depending exactly on what your software does, may take longer because of the extra work to extract individual color component values.<br><br>Dan East