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        *                                              /

