Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!bunyip.cc.uq.oz.au!marlin.jcu.edu.au!cpca From: cpca@marlin.jcu.edu.au (Colin Adams) Newsgroups: comp.sys.amiga.advocacy Subject: Re: (Video) Hardware Idiots ? Message-ID: <1991Jun10.072904.21692@marlin.jcu.edu.au> Date: 10 Jun 91 07:29:04 GMT References: <17259@chopin.udel.edu> <1991Jun10.034118.17541@marlin.jcu.edu.au> <1991Jun10.050457.29319@mintaka.lcs.mit.edu> Organization: James Cook University of North Queensland Lines: 103 In article <1991Jun10.050457.29319@mintaka.lcs.mit.edu> rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) writes: >In article <1991Jun10.034118.17541@marlin.jcu.edu.au> cpca@marlin.jcu.edu.au (Colin Adams) writes: >>In article <17259@chopin.udel.edu> don@chopin.udel.edu (Donald R Lloyd) writes: >>> So, Marc, when did CBM send you their official timetable? Or is it the >>>other way around, with you telling _them_ exactly what's going on? It must >>>also be nice to have every present and future 3rd party in the Amiga market >>>reporting to you to let you know what they're working in so that you'll be able >>>to make such statements as the above based on real, factual knowledge. >> >>Look stop flaming Marc when he is basically right! C= will take at >>least 2 years to get device independance working, considering their >>limited resources and the amount of time 2.0 has taken. Changing the >>graphics library to handle chunky pixels is hard work, and I feel most >>of the the calls will need new ones, with old software using the old >>calls for compatibility. C= will take a LONG time to do this!! > >Basically, I could patch WritePixel, ReadPixel, BltBitMap, Text, >and most of the other gfxlib functions right now to use >another graphics board. The hard part is dealing with the copper >and sprite issues, however, how many APPLICATIONS call MrgCop? I'd guess at quite a lot. I know several of mine do, including the ones without views. It's a nice way to do a new palette change. It's the copper and sprite functions that are difficult (maybe impossible on many pieces of hardware). >My guess is, typical productivety stuff only uses the high level portable >graphics calls. (Move, Draw, WritePixel, DrawImage, DrawBorder, etc) Give a programmer a heap of calls, and they'll generally figure a way to use every one they can. > Most of intuition and workbench call graphics and layers functions so >most of the work has to be done on layers and graphics. I think >CBM could add DIG in about a year considering 2.0 already has some hooks >geared for it (the monitor files, Displayinfo, the scale routines) Maybe, but since they were only advertising for the job last August (from someone else's post, I can't remember when it was), I doubt it. >>Ha, 640*400 is FAR FROM adequate. If you've ever used a more powerful >>machine you'll know that. Just because you don't need colour and I >>don't need colour doesn't mean nobody needs colour. > > Why don't you define adequate for us PLEASE. 640*480 is adequate >for desktop publishing. Personally, I'd like to define adequate as >2048x2048 x 24bit color, 8 bits alpha, 16 bits Zbuffer, 2 overlay planes, >1 control plane for a grand total of 51 bitplanes! Of course I'd want >real-time rendering with 1,000,000 fill-shaded polygons a second for >my virtual_reality simulation. Let's be realistic here, you're acting >like a childish kid just because a $500 machine doesn't have the >graphics power that a $10,000 workstation has. The fact is that the Amiga 3000 doesn't have these capabilities and they cost $6500 here. You ask what is adequate, well 1024*768 at the least is adequate. I prefer at 1000*1000, but I realize the cost probably won't be worth the extra. You rave on a lot about features from a silicon graphics machine, pointless. I just would like to match a 200$ super vga card. > > You can get memory protection with Amiga UNIX. Memory protection >is very difficult to add into AmigaDOS and obviously you're too >clueless to understand why. The MacOS nor MS-DOS have memory protection, >neither does TOS on the Atari ST. What's you point. You want a >multiuser workstation? Buy a UNIX machine. Really hey. I don't have a clue, right. You guys really do bullsh** sometimes. I know all about the message passing code, cause I've written some code that would break if full memory protection was suddenly implemented, or even resource tracking for that matter.... But C= could start adding MEMF_PROTECT flags and try protecting some of the OS tables/low memory from destruction. It would make programming a LOT easier. And blaming an OS fault on programmers isn't good enough. I can't see myself being able to buy bugless software for a long time. As for other machines, protection is coming very soon, and everyone seems to have given up on the Amiga. NeXT has it, Windows 386 has a protected mode (no idea if it works, but if it doesn't it prob. will for 3.1) and I doubt the Mac is far off it (notice it copies messages instead of using pointers, as somebody mentioned before). > Please explain why 640x480 is not sufficient for productivety >software? In case you didn't know, most personal computers on the market >today use 640x480 as the standard mode. Last time I looked, a LOT of people were using 1024*768. I look around me and I can see only one computer with a resolution of 640*480 (an Apollo), which nobody uses because the screen is too small. >-- >/ 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 * / -- Colin Adams Computer Science Department James Cook University Internet : cpca@marlin.jcu.edu.au North Queensland 'And on the eighth day, God created Manchester'