Pixel format bug?

I just made a BMP with some dots (kind of a colored heightmap) to place some objects on a terrain - the object being defined by the pixel color.

The problem is: everything works fine on windowed mode, 32bpp - but not if the desktop is 16bpp.

A point that should be 0,255,0, in 16bpp returns 0,252,0!

Just try for yourselves:

Create a image with a single dot in RGB 0,255,0 and save it as mapinfo.bmp, then run the program below:

Graphics3d 640,480, 0, 2
Tex = LoadTexture("mapinfo.bmp")
LockBuffer TextureBuffer(Tex)
rgb = ReadPixelFast(0,0,TextureBuffer(Tex))  
UnlockBuffer TextureBuffer(Tex)
R = rgb Shr 16 And %11111111
G = rgb Shr 8 And %11111111
B = rgb And %11111111

while not keyhit(1)
   cls
   updateworld
   renderworld
   text 10,10, str$(r) + "-" + str$(g) + "-" + str$(b)
   flip
wend
end

Even using the "getcolor" command I get the same problem! Does anyone know anything about this?

Changing the mode to Graphics3D 640,480,16,1 also returns 0,252,0...

EDIT: just remembered that 16bpp has 5 bits per color... but shouldnt it convert/return values beetween 0-255, specially when using ColorRed/ColorBlue/ColorGreen?

16-bit color means that not all values are possible. I think green gets 6 of those bits so there are 2^6 = 64 available levels of green. 252 is one of the but 255 is not.

This should "fix" the problem:

Graphics3D 640,480, 16, 1
Tex = LoadTexture("mapinfo.bmp",1+256)


If GraphicsDepth()=16 Then
   SetBuffer TextureBuffer(tex)
   GetColor 0,0
   R = ColorRed() / 248.0 * 255
   G = ColorGreen() / 252.0 * 255
   B = ColorBlue() / 248.0 * 255
	Color 255,255,255   
   SetBuffer BackBuffer()
Else 
	LockBuffer TextureBuffer(Tex)
	rgb = ReadPixelFast(0,0,TextureBuffer(Tex))  
	UnlockBuffer TextureBuffer(Tex)

	R = rgb Shr 16 And %11111111
	G = rgb Shr 8 And %11111111
	B = rgb And %11111111
End If


While Not KeyHit(1)
   Cls
   UpdateWorld
   RenderWorld
   Text 10,10, Str$(r) + "-" + Str$(g) + "-" + Str$(b)
   Flip
Wend
End

And even better: now I'm reading the bitmap through my own code and dont have to care for desktop bit depth ;)

That won't fix the problem.

It's all down to the graphics card how it deals with 16 bit.

Some have 555, and as you've found 565. Some will emulate 24bit.

The easiest way I've found is to write the pixel to an image buffer and read it back out again. That way you'll get the correct results regardless of the video card.