Newsgroups: comp.sys.amiga.advocacy Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!wookumz.gnu.ai.mit.edu!rjc From: rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) Subject: Re: (Video) Hardware Idiots ? Message-ID: <1991Jun9.082219.7755@mintaka.lcs.mit.edu> Sender: news@mintaka.lcs.mit.edu Organization: The Internet References: <1991Jun8.085839.3556@news.iastate.edu> <1991Jun8.191231 <1991Jun9.012550.19228@news.iastate.edu> Date: Sun, 9 Jun 91 08:22:19 GMT Lines: 120 In article <1991Jun9.012550.19228@news.iastate.edu> taab5@isuvax.iastate.edu writes: >18699@leland.Stanford.EDU> >Date: Sun, 9 Jun 1991 01:25:50 GMT >Lines: 99 > > Just think before flaming next time. Do you honestly believe that the >version of the operating system that contains DIG will go through early >research, development, and beta testing in less than three years? The >beta testing alone will probably take the better part of two years, as >it has with 2.0. Did you ever consider the possibility that C= has been working on DIG for a while now? I remember back in August of last year C= announced that 2.0 would be followed up shortly by 2.1 which would include "Compugraphic Fonts and Retargetable Graphics". The announcement came via a microbytes report on Bix which contained extracts from the CBM News wire. > > The fact is, it is right now impossible to have a Workbench with more >than 16 colors and a non-interlaced resolution higher than 640x480. This >is inadequate compared to the very nice 256-color display you can get on >the MAC LC, for instance. Don't make blanket statements like this if you can't back them up with proof. I can load a program right now that lets me run a 4096 color WB. Also, you can run 2.0 in 1280x200 mode, or use an A2024 and get 1008x1024. You can overscan the standard chip srt to a non-interlaced 764x480 ( less if you want your sprites, or more in PAL mode) How is anything less than 256 colors inadequate? Give me a break. I guess anything the Mac has and the Amiga doesn't is inadequate? Well lets just say that the Mac's 256 color mode is inadequate and anything less then 24bits color + 8 bits alpha + 8 bits Z buffer + 2 overlay planes + 1 control plane is inadequate also. Besides, you ever seen how SLOW the LC is in 256 color mode? First 640x200 was labeled "inadequate" for publishing, now anything less than 256 colors is inadequate? Marc, I don't think you even know what's adequate for anything, period. You just like labeling things anyway you like to support you're arguement. > I would like to take a poll sometime. I am willing to bet that a >very sharp display with lots of colors at a high resolution is a lot >more usable to most people than being able to 'download to a coprocessor >straight out of the box'. I am willing to bet that the ability to do fast animation, sync to sound, and output NTSC are more important to most people, considering lots of colors are generally used for VIDEO publishing. > A good example of how inadequate the current chipset has become is >the absurd number of bizarre hacks that have become available from third- >party companies enhance the chipset. Such hacks include the A2024 >monitor, all display-enhancer and flicker-fixer devices, the HAM-E, >colorburst, DCTV, etc. If the chipset was more adequate for video tasks, >such hacks would not be needed. Bizarre hacks? Maybe you meanif the Mac's architecture was more adequate for video tasks. Let's keep in mind here, the Amiga chipset is far more flexible in outputing video than the Mac's. You probably have to spend $500 on the Mac just to output NTSC video composite and PAL, whereas the Amiga can handle many video standards. > One final thought: if the current chipset is so adequate, why are >so many people bypassing parts of it entirely? I am talking about programs >like CPUBlit, which basically throws the slow blitter out of the window >and lets the faster CPU do its work. If the blitter was adequate, CPUBlit >would not be needed or wanted. Once again you have _NO_ idea what you're talking about. CPUBlit only speeds up TEXT operations because text is usually scrolled by lines, it's better to copy each line (and all it's bitplanes) at once for a screen instead of BLITing the entire bitplanes themselves. CPUblit is intended for 640x200/400 16 color screens because on 16 color hires the blitter is slowed down a lot, and it can no longer blit all 4 planes in one screen frame. What happens is you get that "color flash" that lots of people are familar with. CPUBlit analyzes the blit and determines if the processor can do it faster for stuff like hires text scrolling in 16 colors (so you don't get the flash). The flash is caused by the video hardware redrawing the screen before all the planes are recopied to their new position. >> >>Unless you back up your dysfunctional statements, Marc, you're just here >>to piss people off. >> >>And no, I don't expect you'll reply to this. > > I guess this comes as a surprise to you, then. BTW, I started replying >to your message before I read that last line. I replied to your message as soon as I saw you're name in the header because I knew it would be another clueless post. >> >>> / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / >> >>Dammit, I like .advocacy. >>Sum, sum, sum, sum, sum, sum, sum-mertime... >>Dave Hopper |MUYOM!/// Anthro Creep | NeXT Campus Consultant at Stanford >> | __ /// . . | Smackintosh/UNIX Consultant - AIR >>bard@jessica. | \\\/// Ia! Ia! | Independent Amiga Developer >> Stanford.EDU | \XX/ Shub-Niggurath! | & (Mosh) Pit Fiend from Acheron > ------------------------------------------------------------- > / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / >/ ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / >------------------------------------------------------------ >\ The great thing about standards is that / > \ there are so many of them to choose from. / > ------------------------------------------------------- -- / 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 * /