menzies@altitude.CAM.ORG (Stephen Menzies) (06/28/90)
dfrancis@tronsbox.xei.com (Dennis Francis Heffernan) writes: > Personally, I wouldn't care if they *never* "officially" added 24-bit >color. I have no need for it, and if I did, I'd go get a professional >graphics machine and not a home computer with a thyroid condition. Which 24-bit professional graphics machine do you have in mind? I know of the Personal Iris at 25K+ that runs 30K-70K+(can) ray- tracing software (alittle steep for me if not for you) and then ofcourse there's the Mac. Any ray-tracers or paintboxers out there that are fed up working with Ham and the lack of 24bitcolors? Will the Firecracker24 or Toaster be the solution? Are we going to have 16mil color *and* broadcast quality now for both ray-tracing and paintbox work? Anyone checked out alternative machines, software, prices? -- Stephen Menzies email: menzies@altitude.CAM.ORG
menzies@altitude.CAM.ORG (Stephen Menzies) (06/28/90)
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >In article <3302@crash.cts.com> seanc@pro-party.cts.com (Sean Cunningham) writes: >>In-Reply-To: message from wizard@sosaria.imp.com >>Nobody has realtime 24bit animation (at least 30fps), and sure you can get 24bit always goes to a frame by frame recorder or Abekas digital frame store. >This raised in my mind a sudden practical concern. Much as I'd like to see >_much_ better graphics available for the Amiga in terms of bitplanes, >resolution, and speed, I just realized that I'd rather wait until the High >Definition TeleVision standard is agreed upon and implemented, so that the >current lead in the video marketplace of the Amiga could be carried on into >the next generation of TV, rather than see a lot of development dollars >spent by CBM pursuing private improved displays that would have to be tossed >out and spent again when HDTV comes along. The same money could be providing >wider busses, more speed, additional coprocessors, and so on that could be >used now and still be useful down the line. I respect your concern but it seems to me that the lack of 24 bit is *the* major problem confronting the Amiga and graphics, *now*. Ray-tracing in Ham is tolerable although it places great restrictions on imagery and subject matter. Painting in Ham is intolerable and unnatural (like working with a substance unknown to mankind). The same people that will be looking for a HDTV capable Amiga in the future are the same ones looking at the Amiga right now. And they're not always happy with what they see, ie. lo-res Ham. Commodore would sell a lot more computers to these people if the Amiga could deliver a 24bit/anti-aliased/higher resolutioned graphic in 3D and paintbox work ,now. The money generated from these sales could be used in R&D for HDTV. >Kent, the man from xanth. -- Stephen Menzies email: menzies@altitude.CAM.ORG
gilgalad@dip.eecs.umich.edu (Ralph Seguin) (06/28/90)
>> Personally, I wouldn't care if they *never* "officially" added 24-bit >>color. I have no need for it, and if I did, I'd go get a professional >>graphics machine and not a home computer with a thyroid condition. > > Which 24-bit professional graphics machine do you have in mind? 24 bit graphics has its places. Not everybody needs high speed animation. Things like ray-tracing, CAD (doesn't need 24 bit graphics, but it looks nice 8-), simulations, etc. all are very well suited to 24 bit graphics. Personally, I'll be glad to see 24 bit graphics from Commodore (cause I'm gonna get myself one). What professional graphics machine are you talking about? The thing that I don't understand is that everybody seems to thing that there is a large number of 24 bit graphics boards and machines using them. This is simply not the case. Most Mac II systems come with piddly 4 bit graphics (but are very easily upgraded to 8). There are very few machines out there with 24 bit graphics. The nice thing about the Mac is that their user interface will run on top of a 24 bit or 8 bit card. That is what I'd like to see from Commodore. I understand that they are not sitting on their asses either. They are fully aware of what is going on. See ya, Ralph gilgalad@dip.eecs.umich.edu gilgalad@zip.eecs.umich.edu gilgalad@caen.engin.umich.edu Ralph_Seguin@ub.cc.umich.edu gilgalad@sparky.eecs.umich.edu USER6TUN@UMICHUB.BITNET Ralph Seguin | In order to get infinitely many monkeys to type 565 South Zeeb Rd. | something that actually makes sense, you need to Ann Arbor, MI 48103 | have infinitely many monkey editors as well. (313) 662-1506
terry@comcon.UUCP (Terry LaGrone) (06/29/90)
In article <1990Jun25.232058.9752@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > >In-Reply-To: message from wizard@sosaria.imp.com > resolution, and speed, I just realized that I'd rather wait until the High > Definition TeleVision standard is agreed upon and implemented, so that the The big Blue Computer Company in Armonk, NY recently (last winter) had many large advertisements for developers who knew things about TV and High resolution. That company will be there when HDTV comes out. Will Commodore? Terry LaGrone
seanc@pro-party.cts.com (Sean Cunningham) (06/29/90)
In-Reply-To: message from xanthian@zorch.SF-Bay.ORG I've already experimented with Sculpt and HDTV...I generated some 24bit traces at the SMPTE 240M standard (1930 x 1035 I believe), just to see how long it'd take to generate images for HDTV. In SCANLINE-SNAPSHOT mode (which allows SHINY texture only), it took about 45minutes...at full PHOTO mode, it took just over two hours. Not bad considering each frame for the "Gymnast" demo took nine hours at 320x200 HAM. Oh, I was using a 2500/30 for the rendering...I'd be interested in seeing times using GVP's 50MHz '030 card! Sean //////////////////////////////////////////////////////////////////////////// UUCP: ...!crash!pnet01!pro-party!seanc | ARPA: !crash!pnet01!pro-party!seanc@nosc.mil | " Fanatics have their INET: seanc@pro-party.cts.com | dreams, wherewith they | weave a paradise for RealWorld: Sean Cunningham | a sect. " Voice: (512) 994-1602 PLINK: ce3k* | -Keats | Call C.B.A.U.G. BBS (512) 883-8351 w/SkyPix | B^) VISION GRAPHICS B^) \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
akcs.clemon@wcbcs (Craig Lemon) (06/29/90)
> Personally, I wouldn't care if they *never* "officially" added 24-bit >color. I have no need for it, and if I did, I'd go get a professional >graphics machine and not a home computer with a thyroid condition. > > >Dennis Francis Heffernan | "Remember the words of your teacher, >dfrancis@tronsbox | your master: Evil moves fast, but >...uunet!tronsbox!dfrancis | Good moves faster!" >Original text (c) 1990 | --Partners in Kryme, T-U-R-T-L-E Power! /* Flame On */ Well Thank You, Mr Innovation! I'm glad you're not in charge of Commodore-Amiga. They would still be marketing their 256K Amiga 1000 as the wave of the future with you in charge. For a long time Amiga users have been trying to get rid of the home computer "game machine" impression of the Amiga and get it into business instead of IBM and Apple where people can really use its power. Thanks for your help! I, for one, believe in the Amiga, and the more "power products" we have, the better chance of getting into some real business we have. We're not going to get anywhere with people like you saying that the Amiga isn't, and will never be, good enough...it's just a HOME COMPUTER! /* Flame Off */ for now... IMHO, CBm should be constantly developing new products. They should never develop a "well, we could've used a 68040 but people will be content with the '030 for now" attitude. Keep on the cutting edge. We depend on CBM for the standards for the machine. If a third party device doesn't conform, it probably won't succeed in an Amiga environment. CBM should at least set some sort of standard for 24-bit that at least thrid-party developers can start (unless they have a better idea for it, then they could tell CBM). If in three years, 24-bit graphics is ho-hum and the norm in the computer community, we can't have compatibility problems between boards. I'm not saying that all should be the same...the developers can enhance their performance and speed all they want but there should be a standard way to choose resolution and bit planes and display them. Intuition and all existing programs would run under the 24-bit system, even if it didn't use all its capabilities. This way 24-bit display could become standard on hte motherboard and all older, non-24-bit software would run. You'll have to excuse my rambling, but these are my opinions. Flames welcome (to a point ;-), opinions welcome. Heck! I can't stop you from doing anything 8-) -- _ Craig Lemon // |_| Kitchener, Ontario \X/ | | M I G A Amiga 2000 -- 2400 bps -- AmigaUUCP 1.03D uunet!watmath!xenitec!wcbcs!lemsys!clemon uunet!watmath!xenitec!wcbcs!{_clemon|AKCS.clemon} ^^ Not Reliable Yet "Yes, it's my real name!!"
bobl@pro-graphics.cts.com (System Administrator) (07/13/90)
In-Reply-To: message from akcs.clemon@wcbcs > IMHO, CBm should be constantly developing new products. They should > never develop a "well, we could've used a 68040 but people will be content > with the '030 for now" attitude. Keep on the cutting edge. We depend on > CBM for the standards for the machine. If a third party device doesn't > conform, it probably won't succeed in an Amiga environment. CBM should at > least set some sort of standard for 24-bit that at least thrid-party > developers can start (unless they have a better idea for it, then they could > tell CBM). If in three years, 24-bit graphics is ho-hum and the norm in the > computer community, we can't have compatibility problems between boards. > I'm not saying that all should be the same...the developers can enhance > their performance and speed all they want but there should be a standard way > to choose resolution and bit planes and display them. Intuition and all > existing programs would run under the 24-bit system, even if it didn't use > all its capabilities. This way 24-bit display could become standard on hte > motherboard and all older, non-24-bit software would run. > Craig Lemon // |_| Actually, if CBM is going to produce a graphics standard for the machine, it should be a 32 bit standard instead of 24 bit. Most of the real graphics oriented machines utilize 32 bits of information for transparency, fog and many other effects. Why should the Amiga be limited to a 24 bit standard when the Mac is currently supporting 32 bit quickdraw? I'n not saying that CBM should make the built in graphics 24 or 32 bit, but the system should be built around it so that we, as users, can pick a graphics card to fit our needs, be that 8 bit on up to 32 bit. That is the solution for the people who are happy with HAM and the other Amiga resolutions currently and also for those who have the money and the need for more professional output. I think that the best of both worlds at this point would be to at least update the Amiga to a full 8-bit system at least in the current resolutions we do have with overscan and interlace. I would then expect Dpaint III to be updated to support 8-bit color. Just these two changes would go a long way to fulfilling many users needs. Of course it's up to EA to deal with Dpaint but it is up to CBM to set the standard graphics routines and output. -- Bob ________ Pro-Graphics BBS - It's better than a sharp stick in the eye! ________ InterNet: bobl@pro-graphics.cts.com | Pro-Graphics: 908/469-0049 UUCP: ..crash!pro-graphics!bobl | CServe: 70347,2344 ARPA/DDN: ..crash!pro-graphics!bobl@nosc.mil | Amer. Online: Graphics3D ___________ ____________ Raven Enterprises - 25 Raven Ave. Piscataway, NJ 08854
seh@pmafire.UUCP (Steve Holaday) (07/13/90)
I agree that a new graphic standard should be 32 bits (per pixel). However only 24 bits are needed for the color information which will give you around 16 million colors (2^24). This essentially covers all visible colors. The remaining 8 bits should be used for attributes, such as blinking, depth, alt. pointers, etc. This will fit in good with a 32-bit bus. BTW the pallet should only needs to be large enough to display 1 million pixels (2^20 or less). This will allow each pixel of a 1024 by 1024 display to be a different color. This should be more than enough for quite some time :-). Unfortunately a 640 by 400 display at 32 bits occupies just under 1 Meg Byte. For dual playfields, double this. That *is* a lot of information which may not be practical to implement. ...Just my $0.02 :-). -- mail: seh@pmafire.UUCP Steve Holaday or !uunet!pmafire!seh I *HATE* long signature files!
seanc@pro-party.cts.com (Sean Cunningham) (07/15/90)
In-Reply-To: message from seh@pmafire.UUCP To me, a 32bit graphics board over a 24bit graphics board, or graphics standard for that matter, isn't too important...the final image from either would look the same, and would be made up of only 24bits. What WOULD be more practical, would be a 32bit, or 48bit standard which used the uper 8bit/24bits as a Z buffer for hidden surface removal when working with 3D. There are systems from Appolo and other workstation manufacturers with some 64 and 96 bits of information PER PIXEL...but all are only 24bits for color information. Sean //////////////////////////////////////////////////////////////////////////// UUCP: ...!crash!pnet01!pro-party!seanc | ARPA: !crash!pnet01!pro-party!seanc@nosc.mil | " Fanatics have their INET: seanc@pro-party.cts.com | dreams, wherewith they | weave a paradise for RealWorld: Sean Cunningham | a sect. " Voice: (512) 994-1602 PLINK: ce3k* | -Keats | Call C.B.A.U.G. BBS (512) 883-8351 w/SkyPix | B^) VISION GRAPHICS B^) \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
andrey@coil.caltech.edu (Andre T. Yew) (07/16/90)
In article <3525@crash.cts.com> seanc@pro-party.cts.com (Sean Cunningham) writes: >In-Reply-To: message from seh@pmafire.UUCP > > >To me, a 32bit graphics board over a 24bit graphics board, or graphics >standard for that matter, isn't too important...the final image from either >would look the same, and would be made up of only 24bits. What WOULD be more >practical, would be a 32bit, or 48bit standard which used the uper 8bit/24bits >as a Z buffer for hidden surface removal when working with 3D. > >There are systems from Appolo and other workstation manufacturers with some 64 >and 96 bits of information PER PIXEL...but all are only 24bits for color >information. > >Sean Has anyone seen the Silicon Graphics Powervision series? I've heard that some machines have up to 268 (268 -- not a typo) bits per pixel. Now, what would one want to use 268 bits per pixel for? Well, I assume some of it goes to Z-buffering, but the more interesting uses I've heard for it are hardware texture mapping, hardware fog, and hardware motion-blur. All of these probably become real-time effects, too. I think the overriding thing here is real-time, and hence interactive. A board with such a big memory for its screen can probably have a real effect on Amiga programs. For example, instead of passively watching the next BADGE Killer Demo contest winner, we can also adjust the camera position and lighting real-time, or grab a corner of a room in the demo, and spin the whole scene around while the demo is still playing. IMHO, Amiga demos are neat right now, but they seem to be mostly the same -- passive -- and those demos I've seen that are interactive aren't really very interesting (press this button to make your figure jump), so if you want some neat ideas, find somebody with a SGI, and go bother them to let you play with it for a while. You might want to try the Jello demo first; it's sort of like Boing! except you have an icosohedron made out of Jello in a transparent cube that you spin around, and watch the Jello fall, jiggle, bounce, and roll around. I know, I know, this is pretty unrealistic, expecting an Amiga to compete, on the very least, with a $32.5K machine, but I feel that current Amiga applications could go so much farther if programmers had more to look at for inspiration. - Andre andrey@tybalt.caltech.edu
peterk@cbmger.UUCP (Peter Kittel GERMANY) (07/16/90)
In article <1990Jul13.144616.21100@pmafire.UUCP> seh@pmafire.UUCP (Steve Holaday) writes: >BTW the pallet should only needs to be large >enough to display 1 million pixels (2^20 or less). This will allow each >pixel of a 1024 by 1024 display to be a different color. Er, if you store 24 or 32 bits per pixel, you simply don't need any palette! But your argument sounds interesting: If you can afford to limit yourself to 1 mio pixels then only 10 bit per pixel would again be sufficient, cutting memory consumption by a factor of 2 to 3. But would that be worth the new limitations? -- Best regards, Dr. Peter Kittel // E-Mail to Commodore Frankfurt, Germany \X/ rutgers!cbmvax!cbmger!peterk
seanc@pro-party.cts.com (Sean Cunningham) (07/17/90)
In-Reply-To: message from andrey@coil.caltech.edu While the graphics on the SGI machine may be very interactive, they still aren't "real-time." Real-Time graphics would mean that they were rendered and interactive at 30 frames per second. Not even the largest Cray can render, fully shaded 24bit images at this speed. Even though it's wireframe, have you ever messed around with CALIGARI, even the demo? It's VERY interactive, even on a stock 7.16MHz A500...now, if someone would include a module for, say an i860, or Motorolla's new "Media-Engine" chip that does 10 instructions per cycle (!!!), we might get close to the performance of an SGI Iris... SEan //////////////////////////////////////////////////////////////////////////// UUCP: ...!crash!pnet01!pro-party!seanc | ARPA: !crash!pnet01!pro-party!seanc@nosc.mil | " Fanatics have their INET: seanc@pro-party.cts.com | dreams, wherewith they | weave a paradise for RealWorld: Sean Cunningham | a sect. " Voice: (512) 994-1602 PLINK: ce3k* | -Keats | Call C.B.A.U.G. BBS (512) 883-8351 w/SkyPix | B^) VISION GRAPHICS B^) \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
scotth@corp.sgi.com (Scott Henry) (07/17/90)
In article <3568@crash.cts.com> seanc@pro-party.cts.com (Sean Cunningham) writes:
At the risk of sounding like a salesrep, I can't let apparent
misinformation go unchallenged:
Sean> In-Reply-To: message from andrey@coil.caltech.edu
Sean> While the graphics on the SGI machine may be very interactive, they still
Sean> aren't "real-time."
My guess from your comments is that you've only seen a PI (Personal Iris),
whivch is by far (almost a factor of 200) the slowest member of the family
in 3D rendering speed.
Sean> Real-Time graphics would mean that they were rendered and
Sean> interactive at 30 frames per second. Not even the largest Cray can
Sean> render, fully shaded 24bit images at this speed.
Unless you have a different definition of the term "fully shaded 24bit
images" than the industry uses, (I could start a flame war and say: "you
don't know what you are talking about", but I'll just say) you are
mistaken. Even the now lowly GT graphics (middle of the performance line)
can interactively generate moderate complexity (2k-5k polygons lighted
gauraud-shaded and z-buffered) with with frame rates of 20-60 per second.
A specific example I am familiar with ('cause it prints out the data), a
model of the X-29 fighter (with a couple thousand polygons), refreshes on
a GT at 29 frames/second. On the VGX (the high end, at 1,000,000 lighted,
shaded polygons/second, or 20x a GT) can do radiosity lighting at >30
frames/second on a complex scene. According to one of the marketroids I
talked to, the VGX can outdo a Cray & fast framebuffer on many types of
image generation (he did not elaborate).
Sean> Even though it's wireframe, have you ever messed around with
Sean> CALIGARI, even the demo? It's VERY interactive, even on a stock
Sean> 7.16MHz A500...now, if someone would include a module for, say an
Sean> i860, or Motorolla's new "Media-Engine" chip that does 10
Sean> instructions per cycle (!!!), we might get close to the performance
Sean> of an SGI Iris... SEan
The Amiga is a wonderful home computer, but it certainly can't render
stuff with the speed of an Iris, which is about the only thing I'd trade
my Amiga for... Can't wait for employee purchase programs...
Back to our usual computer discussions...
--
Scott Henry <scotth@sgi.com> / Traveller on Dragon Wings
Information Services, / Help! My disclaimer is missing!
Silicon Graphics, Inc / 'Under-achiever and proud of it!' -- Bart Simpsonckp@grebyn.com (Checkpoint Technologies) (07/17/90)
In article <285@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1990Jul13.144616.21100@pmafire.UUCP> seh@pmafire.UUCP (Steve Holaday) writes: >>BTW the pallet should only needs to be large >>enough to display 1 million pixels (2^20 or less). This will allow each >>pixel of a 1024 by 1024 display to be a different color. > >Er, if you store 24 or 32 bits per pixel, you simply don't need any >palette! But your argument sounds interesting: If you can afford to >limit yourself to 1 mio pixels then only 10 bit per pixel would again >be sufficient, cutting memory consumption by a factor of 2 to 3. >But would that be worth the new limitations? That color palette would be a million entries of 24 bits each, meaning three million bytes of 4ns color palette RAM. For some strange reason, this sounds very expensive to me... Actually, if you're going to do 24 bit pixels, then I'd suggest something like three palettes of 256 entries each, a palette each for three 8 bit pixels, mixed together for the final image. I wouldn't want to lose the color palette entirely on 24 bit pixels; there's some value to remapping colors without rewriting the pixels, for many applications that aren't basic image processing. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
gavin@krypton.asd.sgi.com (Gavin A. Bell) (07/17/90)
In <1990Jul15.183009.21518@laguna.ccsf.caltech.edu> andrey@coil.caltech.edu (Andre T. Yew) writes: > Has anyone seen the Silicon Graphics Powervision series? I've heard >that some machines have up to 268 (268 -- not a typo) bits per pixel. Now, >what would one want to use 268 bits per pixel for? Well, I assume some of >it goes to Z-buffering, but the more interesting uses I've heard for it are >hardware texture mapping, hardware fog, and hardware motion-blur. For the curious, those 268 bitplanes are used for: 24 bits RGB, frontbuffer 8 bits alpha (used for transparency), frontbuffer 24 bits RGB, backbuffer 8 bits alpha, backbuffer (two buffers for smooth animation) 24 bits z-buffer (used for hidden-surface elimination) 8 bits stencil (used as a very sophisticated image mask, with which effects like computational solid geometry or or shadows may be done in real time) 96 bits for storage of texture maps (images to be mapped onto the polygons drawn) 64 bits for the 'accumulation buffer'. By adding together several images into the buffer (and later dividing by the number added), effects like motion blur, depth of field, and full-scene antialiasing are possible. 8 bits are a window identifier, used by the windowing system to keep track of which window is being drawn into (this allows no penalty for having multiple, arbitrarily shaped windows) and what display-mode each window is in. 4 bits used by the window manager to implement pop-up menus. ----- 268 bits/pixel * 1280 pixels high * 1024 pixels tall / 8 bits/pixel = about 43 megabytes of video ram dedicated to the display. You can buy a PowerVision system with 'only' 140 bits/pixel. Plus a lot of custom hardware to get the 1 million 3D triangles/second drawing rate. Fog is implemented as part of the 3D point transformation process (the color of each point in each polygon is blended to the fog color based on the distance of the point to the eye). True, this all costs more than $100K, but Silicon Graphics Personal Irises have started breaking the $10K price barrier, and prices will continue falling just as surely as Silicon Graphics will come out with something that will blow PowerVision away (in a few years...). --gavin -- --gavin (gavin@sgi.com, (415)335-1024)
jayavant@hpfcdj.HP.COM (Rajeev Jayavant) (07/18/90)
>>/ hpfcdj:comp.sys.amiga / andrey@coil.caltech.edu (Andre T. Yew) / 12:30 pm Jul 15, 1990 / >>In article <3525@crash.cts.com> seanc@pro-party.cts.com (Sean Cunningham) writes: >>>In-Reply-To: message from seh@pmafire.UUCP >>> >>> >>>To me, a 32bit graphics board over a 24bit graphics board, or graphics >>>standard for that matter, isn't too important...the final image from either >>>would look the same, and would be made up of only 24bits. What WOULD be more >>>practical, would be a 32bit, or 48bit standard which used the uper 8bit/24bits >>>as a Z buffer for hidden surface removal when working with 3D. >>> >>>There are systems from Appolo and other workstation manufacturers with some 64 >>>and 96 bits of information PER PIXEL...but all are only 24bits for color >>>information. >>> >>>Sean I think we're really starting to get off track here. The original point being made was that the graphics library should not limit its support to 24 bit boards but rather consider a superset, e.g. 32 bit graphics. This is definitely the right way to go in the long run. Just because the library supports 32 (or 256 or whatever) number of bits does not mean that my graphics board should have to do the same. The library should either emulate missing functionality or provide some reasonable mapping for graphics devices with less features. A couple of examples from HP's Starbase library are emulation of 3D transformation functions when using 2D graphics devices and using dithering when running with a limited number of image planes. In some cases, emulation is not possible and the function must return an error status for the program to handle however it sees fit. >> Has anyone seen the Silicon Graphics Powervision series? I've heard >> that some machines have up to 268 (268 -- not a typo) bits per pixel. Now, >> what would one want to use 268 bits per pixel for? Well, I assume some of >> it goes to Z-buffering, but the more interesting uses I've heard for it are >> hardware texture mapping, hardware fog, and hardware motion-blur. All of these >> probably become real-time effects, too. I think the overriding thing here is >> real-time, and hence interactive. A board with such a big memory for its >> screen can probably have a real effect on Amiga programs. There's a lot more than memory out there (i.e. a lot more compute power than quite a few A3000's, though they are very specialized engines). For some really intense applications, I bet you could keep the 68030 pretty busy just feeding data to one of these Powervision engines. >> For example, >> instead of passively watching the next BADGE Killer Demo contest winner, >> we can also adjust the camera position and lighting real-time, or grab a corner >> of a room in the demo, and spin the whole scene around while the demo is still >> playing. IMHO, Amiga demos are neat right now, but they seem to be mostly >> the same -- passive -- and those demos I've seen that are interactive aren't >> really very interesting (press this button to make your figure jump), so >> if you want some neat ideas, find somebody with a SGI, and go bother them to >> let you play with it for a while. You might want to try the Jello demo first; >> it's sort of like Boing! except you have an icosohedron made out of Jello in >> a transparent cube that you spin around, and watch the Jello fall, jiggle, >> bounce, and roll around. There is no reason why the Amiga demos couldn't be made more interactive in the sense of allowing the user to move the camera around, etc. Just don't expect the kind of response you'd get from an SGI or HP box with a dedicated 3D geometry engine (or engines as the case may be). >> I know, I know, this is pretty unrealistic, expecting an Amiga to >> compete, on the very least, with a $32.5K machine, but I feel that current >> Amiga applications could go so much farther if programmers had more to look >> at for inspiration. I remember seeing a posting in comp.sys.amiga about a little company in Mass. that was building a 3D geometry engine for the Amiga based on the i-860. Expected price was somewhere around $10K with some very impressive specs. It'll be interesting to see if they actually have it at Siggraph as announced... >> - Andre >> andrey@tybalt.caltech.edu Rajeev ------------------------------------------------------------------------------ Rajeev Jayavant (rajeev@hpfcla.hp.com) Hewlett Packard - Graphics Technology Division
seanc@pro-party.cts.com (Sean Cunningham) (07/20/90)
In-Reply-To: message from scotth@corp.sgi.com Yo, yo, yo... Don't EVER use the term "home computer" and Amiga in the same sentence... :^) Sean //////////////////////////////////////////////////////////////////////////// UUCP: ...!crash!pnet01!pro-party!seanc | ARPA: !crash!pnet01!pro-party!seanc@nosc.mil | " Fanatics have their INET: seanc@pro-party.cts.com | dreams, wherewith they | weave a paradise for RealWorld: Sean Cunningham | a sect. " Voice: (512) 994-1602 PLINK: ce3k* | -Keats | Call C.B.A.U.G. BBS (512) 883-8351 w/SkyPix | B^) VISION GRAPHICS B^) \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
scotth@corp.sgi.com (Scott Henry) (07/20/90)
Sean> In-Reply-To: message from scotth@corp.sgi.com Sean> Yo, yo, yo... Sean> Don't EVER use the term "home computer" and Amiga in the same sentence... :^) Sean> Sean You mean like: "You could by a low-performance home computer like the PS/1 or a high-performance one like the Amiga"? At least the Amiga deserves the term "computer!" I don't remember who to attribute this .sig to, but it went something like: "how can you call it a computer if it doesn't have pre-emptive multi-tasking?". But I should have remembered to call the Amiga a 'baby workstation'. That's at least true of the A1000, and I am rather spoiled about what a "real" workstation is... :-) :-). -- scott -- Scott Henry <scotth@sgi.com> / Traveller on Dragon Wings Information Services, / Help! My disclaimer is missing! Silicon Graphics, Inc / 'Under-achiever and proud of it!' -- Bart Simpson
Radagast@cup.portal.com (sullivan - segall) (07/21/90)
>In-Reply-To: message from scotth@corp.sgi.com > >Yo, yo, yo... > >Don't EVER use the term "home computer" and Amiga in the same sentence... ^^^^^^^^^^^^^^^ ^^^^^ Aaaah, I said it. Aaargh, I said it again. Aaaaaah! -kls