This article discusses topics which may not be relevant to your systems. It contains discussions of technology which is now largely obsolete. In particular virtually all displays at this time are 24-bits or higher and do not have or need a colour-palette.
In this section:
Between any Windows application and the display hardware there exists a program called a display driver. For every different make of video card there is a different display driver that is either from the Windows installation disks or from the video hardware manufacturer.
From the programmers perspective all drivers should appear the same as all Windows programs must communicate to the video display hardware via the Windows GDI interface. Drivers, on the other hand, will differ dramatically from display card to display card because the structure and types of messages required to control the video display hardware differ for each card. A video driver therefore insulates the programmer from the complexities of hardware.
Windows supports several common display mode resolutions:
640 x 480 x 16 or 256 colours
This is the most compatible mode as all Windows compatible PCs are capable of displaying at this resolution. However, it is very low quality and is now hardly ever used.
800 x 600 x 16 or 256 colours
This is a popular mode as text is readable and there is a larger display area to work with.
1024 x 768 x 16 or 256 colours
This normally used with monitors that are more than 14 inches wide. It is by far the clearest resolution but may suffer from slow updates if the display card is not of the accelerated type.
In 16 colour mode Windows uses a set palette. It holds 'general' colours that are of most use. If the program requires shades or colours that do not exist in the palette, Windows will attempt to dither that colour. Dithering gives a quick effect that often matches the desired colour. It is done by placing pixels of different colours next to each other so that when the user is a suitable distance away from the screen the pixels will appear to be a third colour.
In 256 colour modes there are 256 unique palette entries. Each palette entry is made by setting a red, a green and a blue component. In this mode, when a pixel is written, a value between 0 .. 255 is placed in the display memory. When the display is refreshed the red, green and blue values are 'looked up' and sent to the screen.
There have recently been several new display colour 'depths' added as new hardware has been designed. These high colour modes store the colours directly in the display memory thus avoiding the need for a palette at all. The two most common colour depths are 65535 and 16.7 million. These depths allow each pixel to be set to any one of the possible colours.
If you want to use a wide range of colours whilst avoiding the complexities of managing a palette, one solution is to restrict the usage of your application to desktops operating in high colour mode. For this purpose, you can use the function HIGH_COLOUR_MODE@ to test if the desktop is set to operate in high colour mode.
A call to CLEARWIN_INFO@('SCREEN_NUM_COLOURS') will give the number of colours for the desktop unless this number is greater than 256 (the value 8192 represents all values greater than 256, i.e. a high colour device). A list of palette functions is given in Graphics functions(palette). These are documented in the ClearWin+ User's Supplement.
If the desktop graphics device is not a high colour device, when you draw to the screen, the colour that you get will not always be exactly the colour you specify in the program. This may cause difficulties if you read a pixel from the screen and try to match the colour with one that you have used earlier to draw to the screen. The following program illustrates the problem together with one method of solution. The program draws a set of 'traffic lights'. When the user clicks on any part of the picture, the colour for that part cycles through the sequence: red, amber, green, black.
INTEGER FUNCTION start_cb()
INTEGER FUNCTION fill_cb()
An alternative solution is to use GET_NEAREST_SCREEN_COLOUR@ in place of GET_MATCHED_COLOUR@. The effect is the same but you will probably get a different amber colour on the screen for the following reasons.
When you draw to a screen drawing surface, ClearWin+ filters the colour through its logical palette in order to find an optimum match (we are assuming the device is not a high colour device). When ClearWin+ calls a Windows API drawing function, the result is then filtered through the system palette. Now suppose we call one of the drawing surface functions (such as FILL_SURFACE@) but instead of using a simple RGB value, we use the return from GET_NEAREST_SCREEN_COLOUR@. The effect is to apply the system palette filtering first and this over-rides the ClearWin+ colour optimisation.
The automatic ClearWin+ colour filtering described above may have the effect of slowing the output produced on a drawing surface. You can switch this filtering off by calling USE_APPROXIMATE_COLOURS@(1). When the filtering is switch off, use GET_MATCHED_COLOUR@ in order to get the filtered colour for a particular RGB triplet. This colour is then used in the drawing routines.