Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!snorkelwacker.mit.edu!mintaka!wookumz.gnu.ai.mit.edu!rjc From: rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) Newsgroups: comp.sys.amiga.advocacy Subject: Re: (Video) Hardware Idiots ? Message-ID: <1991Jun10.065129.4135@mintaka.lcs.mit.edu> Date: 10 Jun 91 06:51:29 GMT References: <1991Jun8.085839.3556@news.iastate.edu> <1991Jun8.191231 <1991Jun10.040317.25396@ncsu.edu> Sender: news@mintaka.lcs.mit.edu Organization: The Internet Lines: 77 In article <1991Jun10.040317.25396@ncsu.edu> kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >18699@lelan >Sender: news@ncsu.edu (USENET News System) >Organization: North Carolina State University >Lines: 20 > >jbickers@templar.actrix.gen.nz (John Bickers) writes: > >> A device independent graphics library isn't going to take several years. >> It shouldn't take more than several months. > >Depends on what it supports. Some DIG (lines, circles, even windowing) >can be done fairly quickly. Exactly what I've been saying all along. Kevin, you know as well as I do that Commodore could put out a "quick fix" and have a gfxlib working on other cards overnight. The core of the gfxlib routines are portable (all the geometric primitives like MOve/Draw(), Read/WritePixel, DrawImage/Border(), Text(), BltBitMap (proven by CPUBlit), even AreaDraw/Move/End() with a little help from a scanline filler. In fact, a lot of the gfxlib calls, call other gfxlib calls so only a few of them need to be patched) The Copper and Sprite system might have to be emulated. The VBeam/Horz items in Struct CopIns are SHORTS, so in theory, a RISC board with copper emulation in it's microkernal could wait on any scanline from 0 to 65535 horzontal and vertical. C= could add a flag to DisplayInfo specifying whether a screen mode is capable of supporting a Copper (like it has sprite and draggable flags now) It's a complex problem, but not impossible, and it certainly wouldn't take 2 years, not even 1. Looking at the DisplayInfo structure in the 2.0 includes it's easy to see that C= had planned on DIG for a while. >But a potentially major problem comes up when you also throw in the need >for animation and other such speed-dependent operations, which are almost >always currently handled on the Amiga by the non-DIGish advantages of... > 1) knowing the exact video layout in advance, and > 2) directly diddling the RAM. C= could specify that ALL display boards on the Amiga will use a bitplane layout rather than a chunky format. The roms already have routines for rendering huge chunks of display data (DrawImage and the rest). What C= needs to do is specify an IFF format for screen data (like PICT). ILBM is close, but something less dependent on the chips would be better. >This also brings up a related comment: those outspoken few who now make >fun of DIG (or fairly DIG) systems for "not being fast", might reconsider >their position. For if/when the Amiga gets DIG support (leaving aside >any combined cpu/video cards), then their tune might sharply change to >"Oh but having a choice of cards is much more important than raw speed" :-]. > regards - kevin No, I think DIG could be fairly fast if some assumptions are made to trade flexibility for speed. Like assuming planes are in bitplane format, assuming the video card has a data mover (blitter) or an onboard processor with some microkernal calls for communication between the Amiga and display board. Sure, intelligence devices are more expensive, but they are far better. A Static 1024x768x24 bit display seems to be a waste. Look at CD-I (which I know you are fond of) It uses an OS/9ish OS like AmigaDOS for it's display yet it will still be fast enough for real time interaction. True device independence is very flexible, but slow (such as Display Postscript), sometimes you have to trade off some flexibility for speed. (ok Next users, stay off the Display postscript remark, I mean display postscript is slow for WEAK processors like the 68000/010/020/030. it's fine on the NeXT, but still not good enough for real-time 60fps video ) -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /