Different values with getpixel same color

[kin]

I'm trying to let a code read pixel color values and put it into an array.
It reads an 8-bit bitmap (map.bmp) with black and white pixels.

Strangely.. some solid  black and solid white values are different?

here's my code:

Code (glbasic) Select Expand

DIM color [20][15] // array to put color values in it
LOADSPRITE "map.bmp",0
LOADSPRITE "tile1.png",1
LOADSPRITE "tile2.png",2



main:

DRAWSPRITE 0,0,400 // draw small map on bottom

FOR x=0 TO 19
  FOR y=0 TO 14

      xpos = x*16 // calculate xpos based on tile width
      ypos = y*16 // calculate xpos based on tile height

      color [x][y] = GETPIXEL(x, y+400) // read color value of small map

         IF color [x][y] = 0 // black
           DRAWSPRITE 1,xpos,150+ypos    // draw tile1
         ENDIF

         IF color [x][y] = 16777215 // white
           DRAWSPRITE 2,xpos,150+ypos    // draw tile2
         ENDIF

      NEXT
      NEXT

SHOWSCREEN

GOTO mainbtw.. the small map is 20x15 pixels, the tiles are 16x16

[Quentin]

this "feature" is also described in the help topic for GETPIXEL

The color can differ up to 13% from that which was set before.

[AndyH]

I'd expect that for 16-bit color conversions, sounds like 100% white is coming out at different values?  Should you expect to get that?

[kin]

Well I didn't know what the phrase in helptopic was meant. "was set before"?

I just don't know why most of the white pixels are 16777215 and a few not.
The bitmap was saved  8-bit and  strictly 2 colored.

[kin]

here's a screenshot.

[Kitty Hello]

The 3D hardware renders not pixel exact colors. So, make the "white pixels" if color > RGB(128,128,128) and the others black.

[kin]

well, i'm atually using the pixelcolor to draw huge levels with lots of different tiles.

I could use dim

• [y] to generate levels from text:

0000000000000
0111000111000
0111000111000... etc

but thats a lot of work for detailed levels and hard to use as reference.

[Kitty Hello]

OK, then convert your color to RGB (see FAQ) and allow about 10% difference to the original color. (check the difference with the red component. Green is more accurate than red and blue. (565 bits RGB).

[kin]

Thnx Gernot! I'll check it out

[kin]

Hi! I've tested the app at my work and it works!



I'm not sure but I think this may have something to do with my videocard/settings.
Maybe somewhere on my computer at home, is causing anti-aliasing which causes the edges to be corrupt. I'm gonna post when I find it out!

I haven't tested on the GP2X yet but I'm sure it wont have this issue.

[Kitty Hello]

Put your desktop in 16 bit color mode to be safe. The GP2X has 16 bit color, too.
Also add some safety in the range.

[kin]

ah good to know thnx!

I finally managed to create an engine that can read a small bitmap for huge levels.
When scrolling it only renders what is visible within 320x240 so it's very fast!

I'll put a snippet soon.

GTA clone, here I come!

[Scott_AW]

I know this is old, but my recent work with using getpixel has revealed that some computers can more accurately pick colors.  I think this has a both to do with degrading of ram used for storing video information, possibly effecting systems that share system with video ram.

For example, a heavily used work computer produced off black pixels when black was supposed to be ignored.  Everything else is fine.  My new netbook renders perfectly, at least when regarding black.  My older netbook(1yr+) which has a lot of ware and is showing it fairs a little worse, getting not only off black pixels, but normal colors wrong.  Another person reported having the black pixel where I took samples to find that the range was 5-0, red being highest, then green.

One of my options right now is to simply ignore colors with values 0-5, which seems to be the range of error.  I had planned to address just the problem with black, but now I find that I need to round the color values when my program sets up an object's palette.

Here's some visual test results