Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!peter From: peter@sugar.hackercorp.com (Peter da Silva) Newsgroups: comp.sys.amiga.tech Subject: Re: asd Message-ID: <7360@sugar.hackercorp.com> Date: 23 Dec 90 16:49:40 GMT References: <925@boing.UUCP> <7335@sugar.hackercorp.com> <6301@amiga.UUCP> Reply-To: peter@sugar.hackercorp.com (Peter da Silva) Organization: Sugar Land Unix - Houston Lines: 60 In article <6301@amiga.UUCP> jimm@amiga.UUCP (Jim Mackraz) writes: > Which "higher level" routines, OpenScreen(), with NewScreen>Modes set > to weird values which programs change on the fly and call RethinkDisplay()? OpenScreen would open on an appropriate device. If you want to open a 24 bit screen, you would call OpenScreen with the appropriate bits set. Programs that call OpenScreen without that sort of magic would just get regular Amiga screens on the regular display device. To get a Workbench on the 24-bit screen you'd have to run a program that opened a second workbench screen with that magic set. I *hope* there are no programs that clobber the workbench screen modes. > 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). I think this should be made a *very* high priority. > 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. Yep. I never said it'd be easy. I don't see how it could be so damn hard, though. As you say, the A2024 proves otherwise. It's been done once... > 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". No, you'd need a display program that knows about the new modes. But you should be able to open a workbench screen onto that display if you need to get extra room. > I feel that device-independent graphics for the Amiga for new applications > is high-priority. Porting the Workbench (nee "retargetable graphics") > is secondary. I don't see that these should be seen as different goals: the first must be a way-station to the second. > 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... (choke) Yes, but AutoCad has a much larger market. The number of SVGA cards out there from a single vendor probably beats the total number of high-resolution cards for the Amiga for all vendors, *including* ECS Amigas in that total. -- Peter da Silva. `-_-' .