16 bit colors

morbuz · 10-11-2001, 10:02 AM

I'm reading about how to build up a 16-bit high color mode.
This is supposed to be done by "simple bit shifting and masking operations", but I just don't get it.

Concider the following macros:

Code:

// This builds a 16 bit color value in 5.5.5 format (1-bit alpha mode)
#define _RGB16BIT555(r,g,b) ((b%32) + ((g%32) << 5) + ((r%32) << 10))

// This builds a 16 bit color value in 5.6.5 format (Green dominate mode)
#define _RGB16BIT565(r,g,b) ((b%32) + ((g%64) << 6) + ((r%32) << 11))

What is really going on in these macros?

**doubleanti** · 10-14-2001, 11:21 PM

the modului of the macros mask off the unwanted bits [32 = 2 ^5. 64 = 2 ^ 6]... perhaps they should use the & operator for more clarity... the range of values for 5 bit and 6 bit data are 0 to 31, and 0 to 65 respectively. the << operator moves the masked r, g, and b values into place... since they are masked to 5 and 6 bits, shifting them and adding them keeps their r, g, and b values exclusive of eachother... does this clear it up?

hth...

**Bubba** · 10-31-2001, 02:50 PM

Two problems there.

Clamping using modulus

You really do not have to clamp the RGBs, just ensure that you never pass a value larger than 31 (green will wrap) to your pixel function. But just in case you want to clamp them:

Modulo is slower than using logical AND with powers of 2.

Example: to computer pixel offset
pixeloffset % 65536 -> slower
pixeloffset & 0xFFFF -> faster same result

Precompute
Don't compute those colors on every pixel. Use tables.

Code:

typedef unsigned int WORD;

WORD red[32];
WORD grn[32];
WORD blu[32];

for (int i=0;i<32;i++)
{
  red[i]=i<<11;
  grn[i]=i<<5;  //depending on card
  blu[i]=i;
}

Now for color all you do is:

Code:

WORD color=red[rvalue]+grn[gvalue]+blu[bvalue]

This is assuming you have computed the correct pixeloffset/bank.
Inline asm looks a bit different than actual MASM,but same idea.

Code:

asm
{
mov ax,0a000h      //screen seg - for buffer move seg of buffer
mov es,bx
mov di,word(pixeloffset)   
mov ax,color
stosw
}

You could store all color values as WORDs in a table, but accessing it would be slower than accessing 3 one dimensional arrays. It would also incur a few more multiplies/adds which you don't have to do. However, all bitmaps should be stored as WORDs. Color would correspond to the WORD in the bitmap. All could be done is asm and would be very fast.

gliptic · 11-01-2001, 05:00 AM

Why use WORDs? I guess most of you doesn't program in 16-bit, so DWORDs would be much faster even if the result has to be converted to WORDs later.

**Bubba** · 11-01-2001, 06:45 PM

Yes, you could use DWORDS, but in real mode I doubt the speed would change much. Besides my inline asm does not allow the use of 32-bit registers. It is a 32-bit compiler, but only for Windows and not DOS. So, for protected mode and access to 32-bit registers, I'll have to download DJGPP.....again!!

So, to use DWORDs would just be wasting space in my array.

**doubleanti** · 11-01-2001, 07:20 PM

using dwords to fill 24-bit rgbs is faster than just using 24-bits... i know that much... but so far as using a dword in place a word, i agree... the speed difference [if any] is negligable... especially when compared to the waste of memory...

gliptic · 11-05-2001, 12:41 AM

What do you mean? There is no memory waste! The result is stored in registers. You store the values as WORDs but you zero extend them when you retrieve them. Some compilers may do this wrong.

**doubleanti** · 11-05-2001, 12:45 AM

i was referring to the pixel format's use in when blitting, for example... where extended period storage is used...

gliptic · 11-05-2001, 01:00 AM

Ohh, sorry for that then. But the speed different is pretty noticable between 32 and 24-bit. Moving data to a missaligned memory is very slow and only every fourth pixel is aligned in 24-bit mode. In 32-bit mode, all pixels are aligned.

**doubleanti** · 11-05-2001, 01:11 AM

right, that was my point... [bankswitching on a 24-bit mode was such a hassle... now LFB has freed my soul...] what's the deal about little endian word ordering in 15/16-bit formats with VESA again? i remeber it was used/mentioned, but i forget how or why... thanks...

**Bubba** · 11-07-2001, 11:55 PM

Well, the fastest way to do this would be to use one of the packed MMX instructions. However, since my compiler does not support this......well I can't use MMX.

But, I've downloaded DJGPP again and an IDE for the 32-bit assembler I have. So, it looks like real-mode will also be a thing of the past for me too. Using assembly in protected mode looks.....interesting.

gliptic · 11-09-2001, 12:59 AM

You can use MMX if you are going to convert at least four colors at a time. If you aren't, you won't gain much using MMX. BTW. You can't do table lookups using MMX.

**Bubba** · 11-09-2001, 03:46 PM

If you are not going to use four colors, just zero the fourth one out. You could still use MMX depending on which instruction you use.

**doubleanti** · 11-10-2001, 01:49 AM

having an alpha byte is still very useful though... provided that it's in the context of every pixel however... but having 256 states for every pixel independant of color boggles the mind! maybe some really complicated lifesim would use it... somehow...

10-11-2001, 10:02 AM	#1
morbuz Registered User Join Date: Aug 2001 Posts: 35	16 bit colors I'm reading about how to build up a 16-bit high color mode. This is supposed to be done by "simple bit shifting and masking operations", but I just don't get it. Concider the following macros: Code: // This builds a 16 bit color value in 5.5.5 format (1-bit alpha mode) #define _RGB16BIT555(r,g,b) ((b%32) + ((g%32) << 5) + ((r%32) << 10)) // This builds a 16 bit color value in 5.6.5 format (Green dominate mode) #define _RGB16BIT565(r,g,b) ((b%32) + ((g%64) << 6) + ((r%32) << 11)) What is really going on in these macros? __________________ [Signature here. (Remove this!)]
morbuz is offline

10-14-2001, 11:21 PM	#2
doubleanti Linguistic Engineer... Join Date: Aug 2001 Location: CA Posts: 2,420	the modului of the macros mask off the unwanted bits [32 = 2 ^5. 64 = 2 ^ 6]... perhaps they should use the & operator for more clarity... the range of values for 5 bit and 6 bit data are 0 to 31, and 0 to 65 respectively. the << operator moves the masked r, g, and b values into place... since they are masked to 5 and 6 bits, shifting them and adding them keeps their r, g, and b values exclusive of eachother... does this clear it up? hth... __________________ hasafraggin shizigishin oppashigger...
doubleanti is offline

10-31-2001, 02:50 PM	#3
Bubba Super Moderator Join Date: Aug 2001 Posts: 7,472	Two problems there. Clamping using modulus You really do not have to clamp the RGBs, just ensure that you never pass a value larger than 31 (green will wrap) to your pixel function. But just in case you want to clamp them: Modulo is slower than using logical AND with powers of 2. Example: to computer pixel offset pixeloffset % 65536 -> slower pixeloffset & 0xFFFF -> faster same result Precompute Don't compute those colors on every pixel. Use tables. Code: typedef unsigned int WORD; WORD red[32]; WORD grn[32]; WORD blu[32]; for (int i=0;i<32;i++) { red[i]=i<<11; grn[i]=i<<5; //depending on card blu[i]=i; } Now for color all you do is: Code: WORD color=red[rvalue]+grn[gvalue]+blu[bvalue] This is assuming you have computed the correct pixeloffset/bank. Inline asm looks a bit different than actual MASM,but same idea. Code: asm { mov ax,0a000h //screen seg - for buffer move seg of buffer mov es,bx mov di,word(pixeloffset) mov ax,color stosw } You could store all color values as WORDs in a table, but accessing it would be slower than accessing 3 one dimensional arrays. It would also incur a few more multiplies/adds which you don't have to do. However, all bitmaps should be stored as WORDs. Color would correspond to the WORD in the bitmap. All could be done is asm and would be very fast.
Bubba is offline

11-01-2001, 05:00 AM	#4
gliptic Registered User Join Date: Sep 2001 Posts: 164	Why use WORDs? I guess most of you doesn't program in 16-bit, so DWORDs would be much faster even if the result has to be converted to WORDs later. __________________ // Gliptic
gliptic is offline

11-01-2001, 06:45 PM	#5
Bubba Super Moderator Join Date: Aug 2001 Posts: 7,472	Yes, you could use DWORDS, but in real mode I doubt the speed would change much. Besides my inline asm does not allow the use of 32-bit registers. It is a 32-bit compiler, but only for Windows and not DOS. So, for protected mode and access to 32-bit registers, I'll have to download DJGPP.....again!! So, to use DWORDs would just be wasting space in my array.
Bubba is offline

11-01-2001, 07:20 PM	#6
doubleanti Linguistic Engineer... Join Date: Aug 2001 Location: CA Posts: 2,420	using dwords to fill 24-bit rgbs is faster than just using 24-bits... i know that much... but so far as using a dword in place a word, i agree... the speed difference [if any] is negligable... especially when compared to the waste of memory... __________________ hasafraggin shizigishin oppashigger...
doubleanti is offline

11-05-2001, 12:41 AM	#7
gliptic Registered User Join Date: Sep 2001 Posts: 164	What do you mean? There is no memory waste! The result is stored in registers. You store the values as WORDs but you zero extend them when you retrieve them. Some compilers may do this wrong.
gliptic is offline

11-05-2001, 12:45 AM	#8
doubleanti Linguistic Engineer... Join Date: Aug 2001 Location: CA Posts: 2,420	i was referring to the pixel format's use in when blitting, for example... where extended period storage is used... __________________ hasafraggin shizigishin oppashigger...
doubleanti is offline

11-05-2001, 01:00 AM	#9
gliptic Registered User Join Date: Sep 2001 Posts: 164	Ohh, sorry for that then. But the speed different is pretty noticable between 32 and 24-bit. Moving data to a missaligned memory is very slow and only every fourth pixel is aligned in 24-bit mode. In 32-bit mode, all pixels are aligned. __________________ // Gliptic
gliptic is offline

11-05-2001, 01:11 AM	#10
doubleanti Linguistic Engineer... Join Date: Aug 2001 Location: CA Posts: 2,420	right, that was my point... [bankswitching on a 24-bit mode was such a hassle... now LFB has freed my soul...] what's the deal about little endian word ordering in 15/16-bit formats with VESA again? i remeber it was used/mentioned, but i forget how or why... thanks... __________________ hasafraggin shizigishin oppashigger...
doubleanti is offline

11-07-2001, 11:55 PM	#11
Bubba Super Moderator Join Date: Aug 2001 Posts: 7,472	Well, the fastest way to do this would be to use one of the packed MMX instructions. However, since my compiler does not support this......well I can't use MMX. But, I've downloaded DJGPP again and an IDE for the 32-bit assembler I have. So, it looks like real-mode will also be a thing of the past for me too. Using assembly in protected mode looks.....interesting.
Bubba is offline

11-09-2001, 12:59 AM	#12
gliptic Registered User Join Date: Sep 2001 Posts: 164	You can use MMX if you are going to convert at least four colors at a time. If you aren't, you won't gain much using MMX. BTW. You can't do table lookups using MMX. __________________ // Gliptic
gliptic is offline

11-09-2001, 03:46 PM	#13
Bubba Super Moderator Join Date: Aug 2001 Posts: 7,472	If you are not going to use four colors, just zero the fourth one out. You could still use MMX depending on which instruction you use.
Bubba is offline

11-10-2001, 01:49 AM	#14
doubleanti Linguistic Engineer... Join Date: Aug 2001 Location: CA Posts: 2,420	having an alpha byte is still very useful though... provided that it's in the context of every pixel however... but having 256 states for every pixel independant of color boggles the mind! maybe some really complicated lifesim would use it... somehow... __________________ hasafraggin shizigishin oppashigger...
doubleanti is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Decimal to 16 bit unsigned?	blurx	C Programming	5	10-16-2008 01:56 PM
How to set an 32 bit allocation to 31 bit for address, 1 bit for flag?	franziss	C Programming	7	12-10-2004 08:18 AM
bit patterns of negtive numbers?	chunlee	C Programming	4	11-08-2004 08:20 AM
Copy bit to bit	Coder2Die4	C Programming	15	06-26-2003 09:58 AM
Array of boolean	DMaxJ	C++ Programming	11	10-25-2001 11:45 PM