# Detect colour of pixel (Release Announcements)

Has there been any recent development in this area. QuickBasic had a command - point(x, y) - which gave the QB color number of the pixel at x,y, eg. 2 for green.

I'm writing a predator/prey simulation where the prey are pixels of some color different to the predators or the background. If you issue " print pixel(x, y) " in a test rectangle , it prints, say, 4278255360 for green, but if you try code such as "if pixel(x, y) = 4278255360 then (do something)", it doesn't work.

I've tried using white pixels and "if pixel(x, y) > 4294967200", also using clear pixels and "if pixel(x, y) = 0 ( or < 1 ) - still no banana!

Incidentally, the correct value for white is 4294967295, not the value shown in Basic256 (Language Documentation).

## Detect colour of pixel

mmm.

Curious. I believe the issue is the 32 bit color 0Xaarrggbb where aa=alpha, rr=red, gg=green, and bb=blue is getting converted to an unsigned int at one place in the code and a signed int in another. It will take a few days to cypher this one out.

As a solution you could convert the pixel value to HEX and string compare, the RGB function output, or you can compare to the color name and this should always work.

color green

print green
print tohex(green)
print rgb(0,255,0)

rect 0,0,100,100
print pixel(50,50)
if tohex(pixel(25,25)) = "ff00ff00" then print "green"
if pixel(25,25) = green then print "green"
if pixel(25,25) = rgb(0,255,0) then print "green"

## Detect colour of pixel

Thanks, Jim

" if pixel(25,25) = green then(do something) " does the trick for my purposes.

Regards, Ken

## Detect colour of pixel

Been there, done that, got the t-shirt:
http://forum.basic256.org/index.php?id=973

## Detect colour of pixel

This one was a bug in the BISON/YACC script during parse of an integer.

If an integer was larger or smaller than 2147483647 and -2147483648 it would not be treated as a float as it should. The regular expression was not as complex as needed. In versions 1.1.3.0 and before the following is observed and is WRONG...

print 99999999999
print -99999999999
print
print 2147483646
print 2147483647
print 2147483648
print 2147483649
print 2147483650
print
print -2147483646
print -2147483647
print -2147483648
print -2147483649
print -2147483650

displays IN ERROR

1215752191
-1215752191

2147483646
2147483647
-2147483648
-2147483647
-2147483646

-2147483646
-2147483647
2147483648
2147483647
2147483646

This behavior is being fixed in 1.1.3.1, will be added to the test suite, and will be corrected in the next binary release.

Jim