16bit color could fix things.

[Scott_AW]

When switching to 16bit color, I found my getpixel command was much more accurate.

I haven't tried other things that have had issue on different systems yet.  Grabsprite tends to work on some computers and not others.

Lately I found my get pixel routine was very off, completely ignoring white against black in some areas.  But switching to 16bit allowed it to properly function.

[BlueSteel]

in my younger days as a programmer I too used to read pixels. then i came over to the PC and there was no function to do it.. ie: floating memory / unreliable etc.. so i was taught to use arrays as opposed to reading the screen (which i argues is an array of sorts anyway.. and why should i need to have the same thing in memory again) to which i was told that on modern day OS's that its not a good idea as you data could get corrupted or be stale.. that irs best to stick to use arrays and check them.

So which is it.. has it reverted back to the way i used to do it.. or is it still better practice to use arrays / linked lists etc... rather than using pixels

[Slydog]

Here's a portion of the 'GETPIXEL()' help file entry:

Warning: The color returned can differ up to 13% from the actual value for the pixel. 16 bit colored pixels are especially likely to return incorrect information. The reason for this is that some platforms have 16 bit displays - 24 bits of color information is converted down to 16 bits resulting in a loss of accuracy.

It appears as if only 24 bit colour would result in an accurate GETPIXEL() command.
Otherwise, the colour is stored as 24 bit, but down-sized to 16 bit for display.
GETPIXEL() will read this 16 bit colour and convert it back to 24 bit for storing in GLBasic memory.

Perhaps only using "16 bit safe" colours may help, if such a concept makes sense.
ie. what values when converted from 24 to 16 bit, then back again to 24 bit results in the original value.
It would depend on how the colours are converted I guess.

[Scott_AW]

I think the problem happens on systems with 32bit color instead of 24bit.

I'd use the sprite2data functions to convert the data to an array but this also doesn't work on all systems.  Although I haven't tried it with different color modes yet.