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:
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
this "feature" is also described in the help topic for GETPIXEL
QuoteThe color can differ up to 13% from that which was set before.
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?
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.
(http://www.macrossworld.com/mwf/uploads/monthly_01_2008/post-590-1199571388.jpg)
here's a screenshot.
The 3D hardware renders not pixel exact colors. So, make the "white pixels" if color > RGB(128,128,128) and the others black.
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.
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).
Thnx Gernot! I'll check it out ;)
Hi! I've tested the app at my work and it works!
(http://www.macrossworld.com/mwf/uploads/monthly_01_2008/post-590-1199710758.jpg)
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.
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.
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!
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
(http://i206.photobucket.com/albums/bb140/scott_aw/getpixeldifferences.png)