 |
|
|
|
VGA and VESA VBE 1.0+ compliant.
GV applications will run on almost every VGA system as it now incorporates a 16-colour VGA graphics engine. In addition, it can take advantage of 16 and 256 colour SVGA modes when the host has a VESA VBE video BIOS or TSR based VBE loaded. Any VESA VBE version is suitable from 1.0 and upwards.
A special technique for calling the BIOS video bank switch function is implemented whenever possible (and this is possible for the vast majority of video card / VBE implementations). This allows DPMI programs to access the video memory just as fast as real mode applications.
New to version 2.12 is VBE 2.0 and Linear Frame Buffer (LFB) support. Most newer graphics cards support the VESA VBE 2.0 API and provide a LFB. The protected mode version of GV's graphics engine will make use of the LFB when one is available. The two main advantages of VBE 2.0/LFB support are:
Users who wish to run protected mode GV applications on older DOS'es (pre MS-DOS 7.0) should go to the downloads page and get the free FastVid utility to make the most of the LFB.
Interface similar to the Borland Graph unit.
Many of the graphics functions use the same syntax and arguments as Borland's Graph unit, making the interface familiar to many seasoned Turbo Pascal programmers. However, the graphics engine is implemented as a unit (ScrnDriv), not as a kernel + external driver(s) as used by Borland's BGI graphics system. This makes it impossible for the user to "lose" them on his/her hard drive. It also makes for easier programming.
The more complex display elements, such as bitmaps and fonts are implemented as objects.
It's Fast!
All the graphics primitives are written in highly optimised assembler, which includes making use of 80386 instructions when appropriate.
It's Small!
Because ScrnDriv is written almost entirely in assembler. It does not use a video buffer (either in off-screen video, or in conventional memory), making the memory requirements of a GV application only slightly larger than an equivalent TV one.
Bitmaps and Palettes
Graphic Vision can load and display bitmaps of any size. There is no 64k limit. GV also provides a hardware palette management system, whereby the logical palettes provided by the bitmaps (and any other "coloured object") are dynamically prioritised and allocated hardware palette entries accordingly. Logical colours are matched to the nearest hardware colour using the "Colour Cube" algorithm when the combined number of different colours requested by all logical palettes exceed the number of available hardware palette entries. The Graphic Vision engine takes care of all this complex colour management of course, so you don't have to worry about it.
Graphic Vision provides objects that can handle:
All types except JPEG's can be stored in a resource file and attached to the application EXE. Only a few TBitMap methods need overriding to provide an object that can handle other image file formats, such as .GIF.
The Mouse
The 16x16 DOS mouse pointer is next to useless in SVGA modes (it's not that clever in standard VGA modes!), plus many DOS mouse drivers don't support SVGA modes anyway, so GV provides its own mouse cursor animation code that provides a redefinable a 32x32 pixel mouse pointer.
New to version 1.20 was an automatic animated "busy" cursor, implemented as an hour glass where the "sand" falls through to the bottom, then the hour glass rotates so the sand goes back to the top, where the process starts again. This is the best "busy" cursor I've ever seen (though I am a bit biased!).
All this is transparent to your code. The system automatically "goes busy" after a definable number of system clock ticks. The busy state is terminated as soon as your program starts polling for mouse and/or keyboard events again (e.g. in the program's main GetEvent....HandleEvent loop).
It's sad but true that there are still a few DOS mouse drivers that don't report the mouse position correctly in SVGA video modes (which is all they have to do, since GV does the actual animation). Ones that do are the OpenSource CuteMouse drivers.
This excellent little open source DOS mouse driver has a tiny memory footprint and the 2.xx version is the only DOS driver to date that supports the wheel of the newer wheeled mice (under DOS only).
Graphic Vision is so much more
than a graphics engine, it's an object orientated application
framework; sort of like a tower block with none of the furniture
supplied. All you have to know is how the elevator works and provide
the furniture! All the standard GUI elements are there, such as
scrollbars, windows, dialogs, buttons, checkboxes, droplists etc.
Many pre-built dialog boxes are also supplied, such as standard
File Open/Save, Change Directory, Mouse settings and Video Mode
selection. GV also comes supplied with a few standard fonts and
many bitmapped resources and mouse cursors.
A much-improved replacement for the standard DOS.PAS unit is also provided. Not only does the GDOS unit provide more functionality than the unit it replaces, it makes writing of DPMI programs very much easier by providing a standard application interface regardless of whether the target platform is DOS real mode or Dos protected mode (DPMI). Many of the DPMI functions work a lot faster than their equivalents in the DOS unit do as well.
About 95% of the core API is compatible with Borland's Turbo Vision, and indeed, many applications written for TV will convert to GV very easily. The three biggest API differences are:
Since Graphic Vision is based on the Turbo Vision API, it offers all that TV does plus many additional objects, procedures and units for dealing with the graphical environment. This includes support for bitmaps, mouse cursors etc. Most of these features don't have to be used by the programmer doing a simple port of a TV application however. A "straight" TV port will look something like similar to a Windows 95 application, but with fewer icons.
The most important utility supplied with Graphic Vision is RscMake. RscMake is a utility that creates a GV compatible resource file from a simple text source script file and raw low-level bitmap, string table, font and cursor resource files. RscMake accepts Windows 3.x bitmap files (.BMP) for use as icons and sprites, Windows 3.1 mouse cursor files (.CUR) and Win 2.x format raster fonts. This means you can use the Resource Editor supplied with Borland Pascal 7.0 or other Win 3.x resource editor to create your low-level Graphic Vision resources! Many low-level resources are supplied as part of the standard GV distribution.
Other utilities include:
The source code for all the Graphic Vision utilities is supplied with the registered distribution.