Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga.tech
Subject: Re: asd
Message-ID: <6301@amiga.UUCP>
Date: 21 Dec 90 05:26:55 GMT
References: <925@boing.UUCP> <7335@sugar.hackercorp.com>
Reply-To: jimm@amiga.UUCP (Jim Mackraz)
Organization: I and I Computing, Palo Alto, CA
Lines: 111

(Peter da Silva) writes:
)(Dale Luck) writes:
)
)> The basic graphics.library is a very complex interface that includes some
)> very amiga specific concepts such as Sprites- Real and virtual, copper lists,
)> blitter objects-(beam synced and normal), animation objects,
)> multiple viewports, changing resolutions, colormaps all 'multitasking' the
)> monitor.
)
)Ick. Yes, I see the problem. Well, at the very least the calls to the RTG
)should try to map closely to the calls in the graphics.library (maybe have
)an extended RastPort structure with extra colors and so on). I think the
)Sprites, copper lists, and so on can be left out. But the higher level
)routines should remain the same. You want to keep the door open to opening
)Intuition windows on a second head.

Which "higher level" routines, OpenScreen(), with NewScreen>Modes set
to weird values which programs change on the fly and call RethinkDisplay()?

Clearly, it will be hard to pick "routines" or even "features" that
you can retarget reliably.

My suggestion is that this problem rather be addressed by thinking in terms
of "levels of compatibility".  Dale already proved with A2024 mode that
many basic Amiga concepts can be eliminated (sprites, WaitTOF(), colors,...)
and still retain excellent compatibility with the class of programs
that run on the Workbench screen: "graphically vanilla" applications.

Graphics has a rendering model, with simple things like SetAPen()
and Move/Draw; harder things, like BltBitMapRastPort() and bitplane
oriented raster images; plus a display engine, with RethinkDisplay(),
screen-positions, colors--and this is the very engine you want to
"retarget" away from; and some oddities like sprites and beam-sync blits.

I believe that it is possible to port the simple "workbench class"
applications someday, but that will indeed be quite a while (layers
and Intuition have to be ported, first). 

But I don't think that this "emulation" will necessarily be the best way
to write device-independent applications.

For one thing, suppose the "retargeting" supports graphics of varying
resolution.  The "retargeted graphics library" knows how to scale things
(poof, through magic).  How do applications support clicking on graphics
objects?  The input model has to be emulated, and tranformed, as well.

I think that well-established graphics standards have a more planned
set of capabilities for inquiring graphics capabilities, defining and
picking graphics segments, and managing colors.  (Hopefully, better
on-screen font support, and an integrated printing model, too.)

Input notwithstanding, as a simple example consider displaying a
24-bit picture.  It should be a simple and straightforward bit of
procedural standardization, in order to make such display
device-independent.

But clearly, it could not be performed at all by a "retargeted
graphics.library".  All known Amiga graphics operations of image display
count on bitplanes, the Amiga palette, maybe HAM, and specific
(and often vile) information about the relatinoships among display mode,
resolution, and depth.  Just check your favorite slideshow with a picture
saved in productivity interlace mode, to see.

I feel that device-independent graphics for the Amiga for new applications
is high-priority.  Porting the Workbench (nee "retargetable graphics")
is secondary.  Considering that there are hardware tricks to get
a new display controller to share a monitor with the Workbench, even to
overlay Intuition windows on the controller's native modes, I
suspect that these solutions will precede retargetable graphics.

Even a standard for slide-show display would have great value now, and
perhaps it can be stacked on top of the 24-bit ILBM standardization effort,
or you can sign up the hardware vendors afresh.

C= probably has to speak with a device-independent graphics standard,
and I agree with Dale's earlier advice that it be some well-established
standard, but I don't know which one I would pick if tasked.

I know that C= has tossed TIGA around a lot (on the agenda (again?) for
European DevCon).  Interesting question: if every device had TIGA,
could you use it to write the simple device-independent slideshow for
24-bit ILBM's?

How about for anims?

Maybe in addition to the established "true graphics" standard, some
standard for amiga-specific constructs like "display 24-bit anim"
be proposed in addition.  Such a thing could be implemented as
a per-graphics-card ilbm device maybe, or even as a protocol for
commands to a rexx port, as far slideshows go.

Very high level.

I would also recommend not getting *too* ambitious, because the
"native implementation" of any bitchen device-independent graphics
will probably be pig slow on an A500; and since that's what C=
tends to sell, most software will have to focus (first, at least)
on native modes to have a market.

Upscale-style graphics standards on the Amiga are probably a
chicken-and-egg problem.  I don't see the pitfalls of myriad
graphics cards being the main reason we don't see workstation
software for the Amiga.  Autocad seems to get by with the
device-specific application driver concept...

	jimm

-- 
--- opinions expressed herein are my own. ---
"... Because they can."
		- profound punchline to joke about dogs