The 32 bit integer used by write/read pixel uses:
The first 8bits to represent the RED component of a colour, the next 8bits to represent the GREEN component of a colour, the next 8 bits to represent the Blue componet and the top 8 bits to represent the alpha component (this is ignored in normal 2D operations and is always set to 255)
To make it clearer:
%11111111100000001000000010000000 - Binary
$FF808080 - Hex
4286611584 - Decimal (-8355712 in Blitz cos it uses signed integers)
In your example above, you can now see that -65536 is $FFFF000 (use Print Hex$(-65536)).
This is indeed pure red with full alpha (Blitz will return always full alpha from a readpixel command [edit]for 2D stuff[/edit]).
Probably as clear as mud...But I tried ;o)
[edit]
The above assumes a 32bit screen mode. Things get really 'interesting' for 16bit modes...
http://www.blitzbasic.com/Community/posts.php?topic=31316
[/edit]
YAN
The first 8bits to represent the RED component of a colour, the next 8bits to represent the GREEN component of a colour, the next 8 bits to represent the Blue componet and the top 8 bits to represent the alpha component (this is ignored in normal 2D operations and is always set to 255)
To make it clearer:
[ A ] [ R ] [ G ] [ B ] %00000000 00000000 00000000 00000000 - Binary A R G B $00 00 00 00 - HexTherefore, if I had a pixel who's RED, BLUE and GREEN components were each set to 128 (mid grey) the integer would look like this:
%11111111100000001000000010000000 - Binary
$FF808080 - Hex
4286611584 - Decimal (-8355712 in Blitz cos it uses signed integers)
In your example above, you can now see that -65536 is $FFFF000 (use Print Hex$(-65536)).
This is indeed pure red with full alpha (Blitz will return always full alpha from a readpixel command [edit]for 2D stuff[/edit]).
Probably as clear as mud...But I tried ;o)
[edit]
The above assumes a 32bit screen mode. Things get really 'interesting' for 16bit modes...
http://www.blitzbasic.com/Community/posts.php?topic=31316
[/edit]
YAN