[Overview][Constants][Types][Procedures and functions][Variables][Index] |
Screen handling unit
uses |
||
|
The system unit |
The Video unit implements a screen access layer which is system independent. It can be used to write on the screen in a system-independent way, which should be optimal on all platforms for which the unit is implemented.
The working of the Video is simple: After calling InitVideo, the array VideoBuf contains a representation of the video screen of size ScreenWidth*ScreenHeight, going from left to right and top to bottom when walking the array elements: VideoBuf[0] contains the character and color code of the top-left character on the screen. VideoBuf[ScreenWidth] contains the data for the character in the first column of the second row on the screen, and so on.
To write to the 'screen', the text to be written should be written to the VideoBuf array. Calling UpdateScreen will then cp the text to the screen in the most optimal way. (an example can be found further on).
The color attribute is a combination of the foreground and background color, plus the blink bit. The bits describe the various color combinations:
Each possible color has a constant associated with it, see the constants section for a list of constants.
The foreground and background color can be combined to a color attribute with the following code:
Attr:=ForeGroundColor + (BackGroundColor shl 4);
The color attribute can be logically or-ed with the blink attribute to produce a blinking character:
Atrr:=Attr or blink;
But not all drivers may support this.
The contents of the VideoBuf array may be modified: This is 'writing' to the screen. As soon as everything that needs to be written in the array is in the VideoBuf array, calling UpdateScreen will copy the contents of the array screen to the screen, in a manner that is as efficient as possible.
The updating of the screen can be prohibited to optimize performance; To this end, the LockScreenUpdate function can be used: This will increment an internal counter. As long as the counter differs from zero, calling UpdateScreen will not do anything. The counter can be lowered with UnlockScreenUpdate. When it reaches zero, the next call to UpdateScreen will actually update the screen. This is useful when having nested procedures that do a lot of screen writing.
The video unit also presents an interface for custom screen drivers, thus it is possible to override the default screen driver with a custom screen driver, see the SetVideoDriver call. The current video driver can be retrieved using the GetVideoDriver call.
Remark: | The video unit should not be used together with the crt unit. Doing so will result in very strange behaviour, possibly program crashes. |
|
Examples utility unit |
|
|
Writing a custom video driver |