brendan@batserver.cs.uq.oz.au (Brendan Mahony) (11/28/90)
In comp.sys.mac.games you write: > I hate to be negative about a machine I love so much, but this just >isn't the case. The Mac doesn't have a little thing called a graphics >coprocessor. Why isn't some industrious third party vendor doing something about producing a low cost graphics/games coprocessor for the Mac? Is it that difficult to intercept calls like copybits and get the processor to implement Quickdraw instead of the rom routines? -- Brendan Mahony | brendan@batserver.cs.uq.oz Department of Computer Science | heretic: someone who disgrees with you University of Queensland | about something neither of you knows Australia | anything about.
EHYOUNK@MTUS5.BITNET (11/29/90)
SuperMac, Radius, and Apple all have products that accelerate graphics in hardware. The only problem is that they are not very cheap! Ed Younk, MTU
ccastcr@prism.gatech.EDU (Russo, Chris A.) (11/29/90)
brendan@batserver.cs.uq.oz.au (Brendan Mahony) writes: > Why isn't some industrious third party vendor doing something about > producing a low cost graphics/games coprocessor for the Mac? Is it that > difficult to intercept calls like copybits and get the processor to > implement Quickdraw instead of the rom routines? I've often wondered the same thing. Two problems come to mind, tho. Being a Mac II owner who loves good games, I think I speak for a lot of people when I say that I don't want to plunk out very much money for this type of thing. And considering problem 2, I think that this would\ be quite a bit. Another thing is the difficulty of implementing what you propose. I think the main problem is a lack of DMA support in the Mac hardware. Even if some reasonable solution were seen to DMA, I think that cost would really start becoming a factor. -- Russo, Chris A. Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!ccastcr Internet: ccastcr@prism.gatech.edu
brendan@batserver.cs.uq.oz.au (Brendan Mahony) (11/30/90)
In <90332.132752EHYOUNK@MTUS5.BITNET> EHYOUNK@MTUS5.BITNET writes: >SuperMac, Radius, and Apple all have products that accelerate graphics in >hardware. The only problem is that they are not very cheap! Look this is exactly the point. We need something in the $200 range, preferably that can be fitted to the compact Mac too. You don't need 24 bit colour for most games. A 4-bit or 8-bit, whichever gives best price/performance, is the way to go. Maybe a scsi device of some sort that plugs into a normal tv for video output? Perhaps a Nintendo? -- Brendan Mahony | brendan@batserver.cs.uq.oz Department of Computer Science | heretic: someone who disgrees with you University of Queensland | about something neither of you knows Australia | anything about.
cookr@cpsin2.uucp (Robert W Jr Cook) (11/30/90)
In article <5963@uqcspe.cs.uq.oz.au> brendan@batserver.cs.uq.oz.au writes: > > Why isn't some industrious third party vendor doing something about > producing a low cost graphics/games coprocessor for the Mac? Is it that > difficult to intercept calls like copybits and get the processor to > implement Quickdraw instead of the rom routines? > >-- >Brendan Mahony | brendan@batserver.cs.uq.oz >Department of Computer Science | heretic: someone who disgrees with you >University of Queensland | about something neither of you knows >Australia | anything about. Well, the Mac can have a graphics coprocessor. The most well known is the Apple 8*24 GC graphics adapter. And its really fast and really nice... Reasons why this product won't appeal to the market suggested (games): - Its *really* expensive, and requires a Mac II (so who cares!) :-) - It accelerates QD calls, but really shines with the GWorld (or is it GOffWorld) stuff first introduced (to me at least) in the first issue of Develop. And please, everyone, correct me if I'm wrong on any of these points... --- Robert Cook CPS @ Michigan State University "cookr@cpsin.cps.msu.edu"
mek4_ltd@uhura.cc.rochester.edu (Mark Kern) (12/07/90)
Why do Mac games use quickdraw commands for their graphics? It would seem
that it would be much faster to a) find out where screen memory resides on
a particular machine. b) reserve that memory for the application. c) Use
assembly language routines that write directly to the screen.
I have not seen an arcade game on the Mac that can compare in graphics to
an IBM, Amiga or even IIGS. I would be interested to know of arcade style
games with detailed background scrolling on the Mac. I have heard that
it is tought to do on a Mac because of having to live with the Toolbox and
Operating System. If someone could point out some good demos of Mac
animation and sound, or just a graphic intensive arcade game, I would
appreciate hearing from you. I'm trying to decide if it would be a wise
idea to try to write such games for the Mac.
Mark E. Kern
P.S. Sorry about that comparason to other machines. I do not want to start
a flame war. Please don't be offended, it is a subjective comparision based
on my personal preferences only. The Mac has great hardware for graphics, I'm
just wondering why I haven't seen it exploited for games yet.
--
=========================================================================
Mark Edward Kern, mek4_ltd@uhura.cc.rochester.edu A.Online: Markus
Quagmire Studios U.S.A. "We not only hear you, we feel you !"
=========================================================================rmh@apple.com (Rick Holzgrafe) (12/08/90)
In article <10844@ur-cc.UUCP> mek4_ltd@uhura.cc.rochester.edu (Mark Kern) writes: > Why do Mac games use quickdraw commands for their graphics? It would seem > that it would be much faster to a) find out where screen memory resides on > a particular machine. b) reserve that memory for the application. c) Use > assembly language routines that write directly to the screen. All that gets you is a guarantee that your game will break sometime down the line, on new hardware or new system software. It's hard to out-draw QuickDraw (on a Mac's hardware, anyway!) QD is written in assembler, uses excellent algorithms, and is optimized to hellandgone (wherever that is). It's true that trap calls are expensive; but you needn't make many for the kind of stuff you're talking about, which would be mostly copying bitmaps around. If you're still worried about trap overhead, you can (at run-time) learn the actual addresses that the traps trap to, and call the routines directly. (This technique also may break in some future system, but it has worked for a long time. Things that bypass QuickDraw break regularly.) A machine with hardware and software designed for arcade-style animation will probably out-perform the Mac every time (just my guess; I'm no expert in these things). If what you want most from your machine is arcade games, you may well be better off with an Atari or an Amiga (or a Nintendo). The Mac can do that kind of stuff, but it doesn't seem to be the Mac's strong suit. Just my opinion. ========================================================================== Rick Holzgrafe | {sun,voder,nsc,mtxinu,dual}!apple!rmh Software Engineer | AppleLink HOLZGRAFE1 rmh@apple.com Apple Computer, Inc. | "All opinions expressed are mine, and do 20525 Mariani Ave. MS: 3-PK | not necessarily represent those of my Cupertino, CA 95014 | employer, Apple Computer Inc."
jmunkki@hila.hut.fi (Juri Munkki) (12/08/90)
In article <11467@goofy.Apple.COM> rmh@apple.com (Rick Holzgrafe) writes: >In article <10844@ur-cc.UUCP> mek4_ltd@uhura.cc.rochester.edu (Mark Kern) >writes: >> Why do Mac games use quickdraw commands for their graphics? It would seem >> that it would be much faster to a) find out where screen memory resides on >> a particular machine. b) reserve that memory for the application. c) Use >> assembly language routines that write directly to the screen. > >All that gets you is a guarantee that your game will break sometime down >the line, on new hardware or new system software. It's hard to out-draw >QuickDraw (on a Mac's hardware, anyway!) QD is written in assembler, uses >excellent algorithms, and is optimized to hellandgone (wherever that is). QuickDraw is optimized for drawing in windows. If all you need is to draw a thin line and you also know that you don't need to clip, you can do a lot better than QuickDraw. About a month or two ago Ben Haller posted an article complaining about the slowness of QuickDraw. IMHO QuickDraw is ok for what it does and probably most parts of it are quite well optimized by now. The true reason to bypass quickdraw in games is that games usually only need a special drawing command that does something simple quickly. Project STORM (not released, but we're working on it) uses only explicitly routines that draw directly on the screen. This is because it redefines how the screen is used. Instead of modifying 8 bits at a time (on an 8 bit deep screen), it modifies just those bits that the game wants. This way you can have multiple independent bitplanes on the Macintosh. >It's true that trap calls are expensive; but you needn't make many for the >kind of stuff you're talking about, which would be mostly copying bitmaps >around. If you're still worried about trap overhead, you can (at run-time) >learn the actual addresses that the traps trap to, and call the routines >directly. (This technique also may break in some future system, but it has >worked for a long time. Things that bypass QuickDraw break regularly.) A technique that will not break in the future is to use QD bottlenecks to do the drawing. These should always be valid entry points to routines that are actually used. You bypass one level of quickdraw dispatching and the trap dispatcher. Couldn't be much faster than that, could it? (Of course this only works with QuickDraw) >A machine with hardware and software designed for arcade-style animation >will probably out-perform the Mac every time (just my guess; I'm no expert >in these things). If what you want most from your machine is arcade games, >you may well be better off with an Atari or an Amiga (or a Nintendo). The >Mac can do that kind of stuff, but it doesn't seem to be the Mac's strong >suit. I agree, but fancy graphics are not what makes a game fun to play. After all, I still like to play many Apple II games that work on my stone-age Apple II+. The 68020 and 68000 are many times faster than the 6502 in the Apple II. The programmers that used to write for the Apple II aren't writing games for the Mac. It's easier to write the game for something else. I think this is the main reason. The most positive new player in the game writers field is the guy who wrote Glider+ and Pararena. I think those games are steps in the right direction. These are simple and interesting games. (I don't find the time to play them-- I like writing stuff more than playing games.) If you want fast arcade graphics, you need a machine designed for it. Most Macintosh users wouldn't want to pay $300 extra just to get hardware support for 32 sprites. After all, the Macintosh uses only one sprite (the mouse cursor). If you want games that are fun to play, you need good programmers. ____________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / Project / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / STORM / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mlab2@kuhub.cc.ukans.edu (12/10/90)
In article <10844@ur-cc.UUCP>, mek4_ltd@uhura.cc.rochester.edu (Mark Kern) writes: > Why do Mac games use quickdraw commands for their graphics? It would seem > that it would be much faster to a) find out where screen memory resides on > a particular machine. b) reserve that memory for the application. c) Use > assembly language routines that write directly to the screen. > Well, if you bypass the Toolbox (directly write to the screen memory) you have a tangle of compatibility problems - different size monitors, b&w with different color depths etc. Using the Toolbox gives you a much more reliable set of routines that will work across different Mac platforms. You may have seen the Defender-clone, MacLanding - it was written in assembly back in the early Mac days. Alas, it doesn't run on the newer machines. > I have not seen an arcade game on the Mac that can compare in graphics to > an IBM, Amiga or even IIGS. I would be interested to know of arcade style > games with detailed background scrolling on the Mac. The IBM and IIGS games tend to write directly to the screen (if I am not mistaken - in fact, isn't there quite a compatibility problem in the IBM world?-VGA, CGA, etc?). The Amiga has additional hardware for dealing with graphics (in addition to it's 'toolbox' routines). No, detailed scrolling with Toolbox commands just crawls on the Mac - you just work within and around your restrictions. On that same note, I haven't seen fast 3D games on the Amiga or IBM - what I mean is full 3D modelling with shading and shadow casting, etc. I know, sounds crazy, but I just thought I'd point out that even the Amiga and IBM programmers must work within some bounds. But, you're right, the Mac programmers have even more restrictions in this regard. > Mark E. Kern john calhoun
duck@engin.umich.edu (Ho Han Chyi Howard) (12/10/90)
In article <27327.276221da@kuhub.cc.ukans.edu>, mlab2@kuhub.cc.ukans.edu writes: |> In article <10844@ur-cc.UUCP>, mek4_ltd@uhura.cc.rochester.edu (Mark Kern) writes: |> your restrictions. On that same note, I haven't seen fast 3D games on the ^^^^^^^^^^^^^^^^^^ |> Amiga or IBM - what I mean is full 3D modelling with shading and shadow I suggest you look at StarGlider II which has been around for sometime now on the Amiga. And I also suggest you check your data about the animation speed of Amiga games. Some are really fast! 8-) ******************************************************************************* * * * Name: Ho Han Chyi Howard ******** * * Address: 1309 S. University Apt #1 *** ******* * * Ann Arbor, MI 48104 *** ***** * * Telephone: local (313)996-1875 (| o o |) * * remote 0-11-65-253-2503 | ^ | * * (Singpore.Equator.SE-Asia.World) \ _ / * * eMail: duck@caen.engin.umich.edu \ / * * 6VBN@ub.cc.umich.edu --- * * * *******************************************************************************
mlab2@kuhub.cc.ukans.edu (12/11/90)
In article <1990Dec9.185637.25796@engin.umich.edu>, duck@engin.umich.edu (Ho Han Chyi Howard) writes: > In article <27327.276221da@kuhub.cc.ukans.edu>, mlab2@kuhub.cc.ukans.edu > writes: > |> In article <10844@ur-cc.UUCP>, mek4_ltd@uhura.cc.rochester.edu (Mark > Kern) writes: > |> your restrictions. On that same note, I haven't seen fast 3D games on the > ^^^^^^^^^^^^^^^^^^ > |> Amiga or IBM - what I mean is full 3D modelling with shading and shadow > > I suggest you look at StarGlider II which has been around for sometime now on > the Amiga. And I also suggest you check your data about the animation speed of > Amiga games. Some are really fast! 8-) > Perhaps I didn't make my point clear... I wasn't trying to slam the Amiga, I was simply trying to pull out of my head an example of something NONE of the personal computers are able to do. If I'm thinking of the correct StarGlider II, they use polygons and depth-searches - basically calculating vertices and filling regions for a solid-hidden-line-removal effect. That wasn't exactly what I meant by shading. Maybe I should have been more specific. What personal computer can do full raytracing with phong shading at 30-40 recalculations a second? Answer - none. My point was simply that ALL machines have their current limitations. I fancy we'll all get a good laugh at StarGlider's graphics in 10 years or so. :) john calhoun > ******************************************************************************* > * * > * Name: Ho Han Chyi Howard ******** * > * Address: 1309 S. University Apt #1 *** ******* * > * Ann Arbor, MI 48104 *** ***** * > * Telephone: local (313)996-1875 (| o o |) * > * remote 0-11-65-253-2503 | ^ | * > * (Singpore.Equator.SE-Asia.World) \ _ / * > * eMail: duck@caen.engin.umich.edu \ / * > * 6VBN@ub.cc.umich.edu --- * > * * > ******************************************************************************* > >
gcarter@globey.cs.wisc.edu (Gregory Carter) (12/15/90)
Never EVER should ANY application be it games or otherwise write straight through to the screen! The software technology problems are bad enough as it is with MultiFinder and the general software environment on the Mac. If you truly want bad software products for the Mac, this is the way to do it! --Gregory