Xref: utzoo comp.sys.amiga:74976 comp.sys.amiga.tech:17175 comp.sys.amiga.hardware:5221 Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!news.funet.fi!ra!rosenber From: rosenber@ra.abo.fi (Robin Rosenberg INF) Newsgroups: comp.sys.amiga,comp.sys.amiga.tech,comp.sys.amiga.hardware Subject: Re: Retargetable graphics. Temporary Stop-gaps. Message-ID: Date: 19 Dec 90 22:59:53 GMT References: <12437@life.ai.mit.edu> <16612@cbmvax.commodore.com> <7307@sugar.hackercorp.com> <1990Dec19.175634.19203@mintaka.lcs.mit.edu> Sender: rosenber@ra.abo.fi Followup-To: comp.sys.amiga Organization: Abo Akademi University, Finland Lines: 65 In-reply-to: rjc@wookumz.ai.mit.edu's message of 19 Dec 90 17:56:34 GMT 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. > 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. > 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). 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 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. ----------- Robin Rosenberg