Path: utzoo!attcan!uunet!cs.utexas.edu!sdd.hp.com!decwrl!adobe!hawley From: hawley@adobe.COM (Steve Hawley) Newsgroups: comp.sys.mac.games Subject: Re: Armor Alley Message-ID: <6704@adobe.UUCP> Date: 24 Sep 90 17:12:10 GMT References: <7194.26FA4B18@fidogate.FIDONET.ORG> Reply-To: hawley@adobe.UUCP (Steve Hawley) Organization: Adobe Systems Incorporated, Mountain View Lines: 127 In article <7194.26FA4B18@fidogate.FIDONET.ORG> Sonny.Shrivastava@f555.n161.z1.FIDONET.ORG (Sonny Shrivastava) writes: >I'm constantly frustrated by game developers bringing 16-color games to >market. Are we back in the old days if IBM CGA color, or what? The Mac > >Are these game companies just lazy to make fancy colorful games? I'm >confused, and would appreciate any clarification anybody has to offer. Here's one viewpoint about writing games for the Mac series of computers: The Mac gives the programmer very little in terms of being able to write a program that will run at TOP speed on a machine (something that is sorely needed for a game). There are no bit blitters, and direct access to the frame buffer is damn near an impossibility on the Mac II (what monitor are you running on? What are its dimensions/depth? Are they running on multiple monitors? etc.). You cannot simply write a game that is speed optimized on a Mac becasue you don't know what hardware you'll be running on. In addition, most software houses will not release versions for each particular machine (ie, II, IIci, IIcx, IIfx etc). Apple has given us QuickDraw. This is a set of graphics primitives that reside in ROM and provide consistent graphics across Mac platforms. The problem: not fast enough. Users want smooth, colorful, flicker-free animation. It takes a LOT of sweat to do this (kudos to Ben Haller for Solarian). Now, as to why not 256 colors: OK, we have established the difficulty of getting fast graphics on the Mac. Let's consider the problem of of magnitude. On the Mac plus/se series you can count on each pixel being 1 bit. You can do a read/write to 16 of the buggers at one time with a single instruction. When you go to color, you start getting hit by increases in the magnitude of work you have to do. 16 colors uses 4 bits per pixel. You now can only read/write 4 pixels in an instruction, but you get a bonus -- 32 bit instructions are more efficient on the 68020 and up which are in the II series so you can now do about 8 pixels in an instruction with fairly good speed, and the machine runs faster than a plus or SE, so you get a win there too. When you ask for 256 colors, you are now using 8 bits per pixel, so it will now take roughly TWICE as long to draw any particular object. Remember how important performance is in a game? Yow. It can really hurt performance to get 8-bit color in a game. You listed Tetris as one of the games that you liked in 256 color. Comparatively speaking, Tetris does not require outstanding graphics performance. The game has a very appealing simple design to it, and doesn't do anything outstanding in terms of animation. That makes it easier to sacrifice speed for detail. Let's consider a favorite Arcade game of mine: Defender. Defender is a 16 color game (as well as Robotron, Stargate and Joust). It looks like a whole lot more colors because of careful use of color table tweaking. It is running on a 6809 microprocessor running at 1 MHz. It has NO special hardware for doing graphics. The entire game was written in assembly language and carefully hand-tweaked to get every cycle out of the processor that it could. The sound effects were done on a totally separate board and used almost none of the main processor's clock time. The main board would write to a memory location, the value signifying the sound effect to make, and then it would pull another byte high. The sound board will then start making that sound effect until it it is told to stop or start another. The next time you happen to see a Defender (or Joust, or Robotron or Stargate) notice that it only makes at most one sound effect at a time. Ok, let's take a look at why a machine that is running at a fraction of the clock speed of a Mac II can do a game faster than on a Mac II. A Defender machines does one and only one thing. It plays Defender. It doesn't do spread sheets, it doesn't run a window manager, it doesn't run floppy drives, SCSI devices, track a mouse, run device drivers, support serial IO, it doesn't run the Multifinder. etc etc. A Mac does do all those things. It is a machine that was designed to be flexible in its applications, not rigid. The user base demands that their software will work on every machine released as is. To provide this in a game, you lose big on performance to maintain compatability. Assuming you will be running on one and only one machine allows you to make some assumptions in your software to boost speed in the game (like assuming where the frame buffer will be and assembling/compiling in the addresses to it so you can unroll your loops, or write self-modifying code). You can't do that on the Mac, or if you do you have to have a special case for nearly every possible configuration. Ouch. This is why Megaroids and Chipwits (remember them?) do not run on anything but the Mac 128's without backpatching the code. Even then, they won't run on a II. This doesn't mean that it CAN't be done. It means that it is almost assuredly going to be very difficult and very time-consuming. In addition, the incentive isn't really there. The Mac market is just not big enough (in comparison to, say IBM PC or Nintendo) to justify the investment in time. Suggestion: if you are unsatisfied with a game, write to the company to tell them so, and ask them why they aren't supporting full color. If you don't complain to them, they won't ever know. I found an amusing bug in the original Choplifter (for the Apple ][): it was possible to get the hostages to safety by landing the copter next to the hostages and then lifting off before they got in and landing a little closer to the safe point. Repeating this, the hostages walk back to safety on their own, and are never registered as being saved since they were never in the copter. Once you have gotten the first 6 (since there are never more than 6 hostages visible at one time) to do this, there are no more hostages. Period. I mailed Broderbund a letter, and got a very nice reply from them. They probably had as much of a laugh about this one as I did. As a game programmer, I knew what was going on and wasn't surprised that they missed this one (it *IS* pretty superficial, and I wasn't playing "by the rules"). The trouble with writing games for the Mac is that there a lot more pitfalls you have to worry about. My advice: Voice your complaint to the manufacturer. Be critically supportive, not antagonistically negative. Ask intelligent, honest questions. Let them know when you think they've done something right. The art of correspondence is being lost. Help revive it. And do report back if you get replies. Steve Hawley hawley@adobe.com -- "I'm sick and tired of being told that ordinary decent people are fed up with being sick and tired. I know I'm certainly not, and I'm sick and tired of begin told that I am." -Monty Python