Mail Archives: djgpp/2000/05/01/19:55:11
david lindauer <dlindauer AT notifier-is DOT net> wrote in message
> The problem with porting turbovision anywhere other than to a text-mode
screen is
> that it has no smarts... if a window needs to be moved in the heirarchy
or
> physically resized or moved on the screen it draws all the lower windows
one by
> one in reverse order (in their entirety) and then draws the moved
window... this
> is fine in text mode where the draws don't take any time but in a graphics
mode
> it would be a major slowing factor when you have several windows up.
That's right, but this is one of the lesser problems. The big problem is
that Turbo Vision is inherently tied to a "character cell" based coordinate
system. This makes it very difficult to port to a graphics screen and still
make it look real swish. However, the first incarnation of my Graphic Vision
library kept the cell-based coordinate system and did a few tricks (cludges
really) to provide a pretty good Borland Pascal based GUI that was almost
100% TV compatible.
However, with Graphic Vision 2.0 I dumped the cell coord system because it
was a liability. Proportionally spaced fonts would have been virtually
impossible, and other things would have been very cludgy. This change
however meant SH!T loads of work and some changes to the API.
So GV 2.0 is less TV compatible than was 1.xx, but still pretty damn close.
Many of the GV 2.0 incompatibilities are not actually due to its graphical
nature, but simply as an improvement to the orginal API. The TV API is
basically sound, but there are flaws - some of them quite serious.
Anyway, for those of you that want to have a look at how good a DOS
application can look and work; download GVFM.ZIP or MAHJONG.ZIP from my
website (see my sig). Borland Pascal owners can download the GV2.0
development suite and compile GVFM.EXE and other demo programs for
themselves.
--
Jay
Jason Burgon - Author of Graphic Vision
New version 2 now available from:
http://www.jayman.demon.co.uk
- Raw text -