Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!wookumz.ai.mit.edu!rjc From: rjc@wookumz.ai.mit.edu (Ray Cromwell) Newsgroups: comp.sys.amiga Subject: Re: Retargetable graphics. Temporary Stop-gaps. Message-ID: <1990Dec20.054258.1952@mintaka.lcs.mit.edu> Date: 20 Dec 90 05:42:58 GMT References: <7307@sugar.hackercorp.com> <1990Dec19.175634.19203@mintaka.lcs.mit.edu> Sender: daemon@mintaka.lcs.mit.edu (Lucifer Maleficius) Organization: None Lines: 86 In article rosenber@ra.abo.fi (Robin Rosenberg INF) writes: >In article <1990Dec19.175634.19203@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: >>In article <7307@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>>In article <16612@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>>At least any such RTG interface should provide the same basic interface as >>>graphics.library. Why even consider anything else? >>> >>>In the previous article, someone not Dave Haynie wrote: >>>> Now I'm not suggesting running Intuition screens on video boards/frame >>>> buffers. >>> >>>Why not? > >Of course we need intuition on the new graphics cards. Let Commodore do this. What I am suggesting is a method of allowing software to render to a 'custom' screen display. Most video software does not use Intuition windows, instead they use custom screens. >> This has been hashed and rehashed before, but I'll explain. Intuition >>and graphics.library are very tuned to the graphics chip set. How >>many frame buffers have sprites? A copper? Scrollable bitplanes? >>A display co-processor? > >The *implementation* of Intuition and graphics.library work very >closely to hardware. But mostly they are a set of routines and >datastructures for drawing graphics and maintaining a user interface. Mostly. But some of the things that make the Amiga special are defined as a fundumental part of that interface. Like sprites, viewports, dragable screens, palette control. >> The sad fact of it is, dragable screens, viewports, super bitmap screens, >>sprites aren't availible on most framebuffers. Some hardware doesn't >>even use bitplane format(for instance, Chunky Pixmaps). >> >> To get around this it may take a year of programming and bug testing >>to emulate this kind of stuff. We can't wait that long. We need something >>to make ray-tracers, paint programs, and video processing software work >>on now. Most of these kinds of programs open up a custom screen and dump >>scanlines to it directly bypassing intuition. > >I suggest that a frame buffer become a new kind of ViewPort, so you >could open a new screen on the frame buffer. The new screen could then >take over the monitor completely (like the A2024) or show up on a >separate monitor. Somehow it would be possible to drag the mouse over >to the other monitor and make its screen the active one. And nothing >would stop us from having any number of monitors, (as many as we can >fit graphics cards into the machine). This is almost the same as tossing out intuition. Your new kind of 'viewport' is virtually the same as my suggestion of a set of primitives for rendering to a custom-display device. >It is quite obvious that graphics.library is not optimal for driving >other types of video hardware than the Amiga custom chips, but it is >definitely possible. Many of the routines aren't based on a bitplane >paradigm and can be translated to any kind of video hardware >relatively easy, WritePixel(), ReadPixel(), MoveTo(), Draw(), >PolyDraw(), Text(), RectFill(), WritePixelArray, etc. Some of the >other routines, e.g. ClipBlit, BltPattern, might require translation >from bitplane to packed pixel format (or whatever is used) and vice >versa, but that kind of translation isn't too hard to do. The work entailed to rewrite the entire graphics library and intuition would be tedious and comprehensive. Its easy to talk about doing it, but try it once. I'm all for doing this, but I know it will be a year atleast before any results, thats why the title of my post is called TEMPORARY STOP-GAP. >The graphics.library is eight bits and that seems to be hardwired into >the design of it, so a new set of calls and structures must be defined >for 24 bit graphics. The old routines would work work ofcourse, >limited to drawing max 256 different colors. > >Of course there would be the programs that do things assuming a >bitplane oriented architechture, but having BOTH the Amigas own video >hardware would make it possible to run these programs on the standard >monitor in a standard view mode. Only new programs would know how to >create a 24 bit screen, and one could allways run Workbench on the >standard monitor. Yet another problem. WritePixel is soooo slow on a standard Amiga,many developers craft their own line drawing/pixel plotting routines based on the bitplane. >----------- >Robin Rosenberg