Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!apple!sat!farren
From: farren@sat.com (Michael J. Farren)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: OS Graphic Card Support: Part II!
Message-ID: <1991Feb23.203900.27912@sat.com>
Date: 23 Feb 91 20:39:00 GMT
References: <18989@cbmvax.commodore.com> <1991Feb18.210422.5446@sat.com> <1991Feb20.090728.2384@kberg.se>
Organization: SAT
Lines: 26

svante@kberg.se writes, in reply to my posting:

>>In short: if anyone builds a VDI equivalent for the Amiga, you'd be
>>doing us all a disservice if it were not reasonably close to the "bare"
>>system interface, both in speed and in utility.
>
>How would this be done? I mean one has to account for most types of
>major hardware in the area. Advantage has to be taken automatically of
>accelerators etc. Please elaborate.

All I was saying was that any VDI scheme that anyone comes up with for
the Amiga should, at the very least, give you all of the capability that
the native ROM calls do.  A VDI with less functionality just won't be
used, or will at least cause much griping and moaning amongst the poor
programmers.  As it is, there are too many times you have to code your own
routines to provide capabilities that AmigaDOS (well, Exec, actually)
doesn't give you.  If a hypothetical VDI does not, for example, provide
the ability to specify the APen and Bpens, along with at least the four
basic text modes JAM1, JAM2, COMPLEMENT, and INVERSE, it won't be used.
Not by *me*, at any rate, unless I absolutely have to, and even then I'll
bitch about it.
-- 
+-----------------------------------------------------------------------+
| Michael J. Farren                                      farren@sat.com |
|                        He's moody, but he's cute.                     |
+-----------------------------------------------------------------------+