[Overview][Constants][Types][Procedures and functions][Variables] |
Screen handling unit
The Videounit 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 Videois simple: After calling InitVideo, the array VideoBufcontains 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 VideoBufarray. Calling UpdateScreenwill 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 VideoBufarray may be modified: This is 'writing' to the screen. As soon as everything that needs to be written in the array is in the VideoBufarray, calling UpdateScreenwill 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 LockScreenUpdatefunction can be used: This will increment an internal counter. As long as the counter differs from zero, calling UpdateScreenwill not do anything. The counter can be lowered with UnlockScreenUpdate. When it reaches zero, the next call to UpdateScreenwill 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 SetVideoDrivercall. The current video driver can be retrieved using the GetVideoDrivercall.
Remark: | The video unit should notbe used together with the crtunit. Doing so will result in very strange behaviour, possibly program crashes. |
|
Examples utility unit |
|
|
Writing a custom video driver |