Path: utzoo!attcan!uunet!husc6!think!ames!oliveb!pyramid!ncc!alberta!dvinci!lowey
From: lowey@dvinci.USask.CA (Kevin Lowey)
Newsgroups: comp.lang.pascal
Subject: Re: Turbo BGI
Summary: Can't blame BGI for incompatible cards!!
Message-ID: <1575@dvinci.USask.CA>
Date: 21 Dec 88 20:39:37 GMT
References: <17918@adm.BRL.MIL>
Organization: University of Saskatchewan
Lines: 56

In article <17918@adm.BRL.MIL>, Pete Mancini writes:

>     For those who applauded the BGI, consider this.  I have been developing
> a graphic intensive program to be used at several sites.  I was very pleased
> with the DETECT ability until one day a very irate user called me.  He had
> a Zenith EGA card in his machine and was getting "a lot of horizontal lines
> across the screen."  As it turns out the BGI detected EGA, but assumed it had
> an EGAHI mode.  This card did not (it was really an enhanced CGA) and thus
> went under when the 'wrong' graphics mode was selected.  The patch for this
> was a procedure that gave a sample image and then asked the user 'Hows this?'
> If Thumbs_Down = true then the setgraphmode command had to be invoked.

  I was going to ignore this but so far I've seen it three times #8-)

  You can't blame the BGI routines if the manufacturer of the graphics card
only implements a subset of the cards functions!!  I'd be upset at Zenith,,
not Borland.

  Also, no matter how good the detection is, all programs should have a way
to override the detection.  Either in a configuration file or in a command
line parameter.  If a programmer does not provide this capability in a
program then he is just asking for trouble.

  For example, I use a DEC VAXmate computer (sigh).  I wrote a TSR program
that allows me to tell software that the VAXmate is actually an AT&T 6300.
This lets me install the video for Lotus 1-2-3, etc. as an AT&T 6300 and get
640 by 400 resolution instead of 640 by 200.  However, the computer still is
a VAXmate, so programs that "detect" what kind of graphics card they should
use default back to the CGA card.  If the authors of the programs provided a
way to override the detection logic and explicitly state what graphics
device to use, it would make my life a lot simpler.

  Related to this, I have written a few programs that use the .BGI routines.
(one I worked on is SURFMODL, a 3d surface modelling program written by Ken
VanCamp).  I found that with most of these programs they expect the .BGI files
to be in the current directory.  This means I have to have the files copied
into many directories on my hard disk.

  In my own programs I've started using the TP version 5 GETENV routine to
get the value of an environment string called BGIDIR.  Then I can do things
like this:

  INITGRAPH (GRMODE, GRTYPE, GETENV('BGIDIR'));

If the environment variable is not defined, then the current directory is used.
If it is defined, then the directory can be used.  In my AUTOEXEC.BAT file I
can say

  SET BGIDIR C:\DRIVERS

and store all my drivers in one directory, instead of all over the hard disk.

  I'd like to suggest that other .BGI developers do the same thing so a
"standard" will develop.

-- Kevin Lowey