Windows graphic modes
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
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
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
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
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
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.