Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!zaphod.mps.ohio-state.edu!wuarchive!uunet!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: OS Graphic Card Support: Part II!
Message-ID: <19189@cbmvax.commodore.com>
Date: 21 Feb 91 16:35:31 GMT
References: <28532.27b759c9@kuhub.cc.ukans.edu> <1991Feb13.064714.9347@ncsuvx.ncsu.edu> <18989@cbmvax.commodore.com> <1991Feb18.210422.5446@sat.com> <1991Feb20.090728.2384@kberg.se>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 40

In article <1991Feb20.090728.2384@kberg.se> svante@kberg.se (Svante Gellerstam) writes:
>In article <1991Feb18.210422.5446@sat.com> farren@sat.com (Michael J. Farren) writes:

>>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.

Essentially, what you want here is a graphics model that exists on several
levels.  At the lowest level, you get real simple stuff, like "draw a pixel",
"draw several pixels", "read a pixel", whatever.  On top of that, you get a
commands like "draw a line", "draw a box", "move a region", "draw a character",
etc.  You might even go higher.  The details aren't really that important.  The 
basic idea is this.  On a dumb display, nothing more than visible memory, the 
graphics interface sends such commands to a program that's running on the host
CPU itself, which will be responsible for implementing all the commands.  It
could do them all via the very low level functions.  Move to something like
the Amiga, where you have a programmable graphics engine, and these commands
get sent to a program on the CPU which converts the commands to blitter
operations, at least for things like block operations, line draw, etc. that
Agnus does well.  Move to something like the A2410, with a graphics oriented
processor, and the commands are sent directly to that processor for 
interpretation, leaving the system's CPU totally free of the process.

Lots of graphics.library could work this way.  Other pieces, like blitter and
copper specific things, would be somewhere between real ugly and impossible
to implement on other display devices.  Although I understand the general
problem, I don't pretend to know how our software folks may be planning to
deal with device independence.

>Svante Gellerstam		svante@kberg.se, d87sg@efd.lth.se


-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	"What works for me might work for you"	-Jimmy Buffett