Colour depths

[Zack]

One of the glorious things about FB is that is supports all sorts of graphics resolutions and colour depths.
In 8-bit depth (the one I'm used to from QB's old SCREEN 13), a number from 0-255 was used to specify colour. But how do I specify colour in higher depths? 16, 24, 32, etc? For 24 I've been using the RGB() function, since it returns 3 bytes and 24 bits=3 bytes. But what about 32 and 16? How would I take advantage of all those millions of colours? And are there 12, 20, and 28-bit depths (all multiples of four)?

[Anonymous]

nope, even in 32-bit youll get only 24 bits worth of color info, you can use the extra 'channel' for alpha blending, or whatever

its just in integers.. 32 bits = 4 bytes

byte 0 = r
byte 1 = g
byte 2 = b

just to get you to understand

[Andrew Collins]

This will demonstrate.

Code:

DIM i AS SINGLE' Integers are in nondecimal...
DIM RedColor,BlueColor,GreenColor AS INTEGER
DIM x,y,newcolor AS INTEGER
SCREEN 20, 32,,1
A=1
DO


FOR i= 1 TO 60000 STEP .05
IF INKEY$=CHR$(27) THEN END  
  
x = INT(RND(1) * 1025)
Y = INT(RND(1) * 769)

RedColor = INT(RND(1) * 256)  
BlueColor = INT(RND(1) * 256)
GreenColor = INT(RND(1) * 256)

NewColor= RGB(RedColor,GreenColor,BlueColor)


PSET (x, Y), NewColor
  
NEXT i
A+=1
LOOP UNTIL A>5

CLS
SCREEN 0
END 0

[quote][/quote]

[Deleter]

nope, even in 32-bit youll get only 24 bits worth of color info, you can use the extra 'channel' for alpha blending, or whatever

its just in integers.. 32 bits = 4 bytes

byte 0 = r
byte 1 = g
byte 2 = b

just to get you to understand

actually blue is the 0 bit, and red is 2. :wink:

[Z!re]

nope, even in 32-bit youll get only 24 bits worth of color info, you can use the extra 'channel' for alpha blending, or whatever

its just in integers.. 32 bits = 4 bytes

byte 0 = r
byte 1 = g
byte 2 = b

just to get you to understand

actually blue is the 0 bit, and red is 2. :wink:

Depends on your endian order, but it's ABGR
And you count from right to left, so.. first byte is R, second is G, etc.. it's easy to test though..

[na_th_an]

Zack, there's just no palette.

Think of old 8 bits SCREEN 13 in QB. You had 256 colours which, in fact, were pointers to a lookup table, which is your palette.

Every palette entry was specified by a 6 bits red value, a 6 bits green value and a 6 bits blue value.

In 16, 24, 32 bits modes you don't use the lookup table, but the r,g,b values directly.

[Zack]

Right. But how does the RGB value fit into the space allocated to it in 16-bit modes? An RGB value is three bytes, and 16 bits is only 2.

[DrV]

Depth: Pixel format:
1 1 byte per pixel, indexed, index ranging 0-1.
2 1 byte per pixel, indexed, index ranging 0-3.
4 1 byte per pixel, indexed, index ranging 0-15.
8 1 byte per pixel, indexed, index ranging 0-255.
15,16 2 bytes per pixel, direct color, RRRRRGGGGGGBBBBB.
24,32 4 bytes per pixel, direct color, AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB.

[Deleter]

nope, even in 32-bit youll get only 24 bits worth of color info, you can use the extra 'channel' for alpha blending, or whatever

its just in integers.. 32 bits = 4 bytes

byte 0 = r
byte 1 = g
byte 2 = b

just to get you to understand

actually blue is the 0 bit, and red is 2. :wink:

Depends on your endian order, but it's ABGR
And you count from right to left, so.. first byte is R, second is G, etc.. it's easy to test though..

well im just used to 32 bit depth
in which if i make a union like so:

Code:

union col
    col as integer
    b(3) as ubyte
end union

dim as col c

and say c.col = rgb(255,0,0)

then c.b(2)=255

...

[na_th_an]

Right. But how does the RGB value fit into the space allocated to it in 16-bit modes? An RGB value is three bytes, and 16 bits is only 2.

Some cards use 5 bits red, 5 bits green, 5 bits blue, 1 unused bit. You get 32768 different colours.

Some others use 5/6/5, allowing for 65536 different colours.