From: english@primenet.com (Lawson English) Newsgroups: rec.games.programmer Subject: Mac Mythconceptions (Was Re: Why Mac not a games platform) Date: 17 Mar 1995 16:36:39 GMT What follows is possibly the best example that I have ever seen of the misconceptions about the Mac that exist in the DOS/Windows/OS/2 programming world. Here are the main points and the reply: 1) There aren't enough Macintoshes out there to make it worthwhile to support or port games for. Actually, according to industry stats that I have read, while the Macintosh may only have 1/10 of the installed base (some claim that it actually has 1/7 of the *functional* installed base as a Mac Plus from 1985 can run System 6 and virtually every business "productivity" app out there at usable speeds), the total software revenues from Macintosh software is about 1/3-1/5 that of the DOS/WIndows revenues. This is said to be because of the ease-of-use factor that allows the average Macintosh owner to be far more productive than the average DOS/Windows user. In addition, Dr. Dobbs Journal has reported that multi-media houses that support both DOS/WIndows *and* Macintosh, find that their customer-support costs for the Mac are far, far lower than they are for the other platform, due to the plug-and-play nature of SCSI CD-ROM drives on the Mac side, and the consistent hardware/software that is the rule with the Apple-made Macintosh (clones may change this but maybe not). 2) Macintoshes are not as backwards compatible as the various generation clones are -especially when dealing with graphics. While there is a certain truth to this (the B&W-only Macs can't do color, in general), the Macintosh video standard has been at least 256 colors since 1986/7, and has been 32-bit (16 million color) since shortly thereafter. *EVERY* color-capable Macintosh has available the options for B&@, 4-color, 16-color, 256 color, 32,000 color, and 16 million color, depending on the built-in video/plug-and-play video. And, since it is plug and play, an application such as a game can read what is available on which video monitor (you can have up to 6 using NuBus cards) and which resolution (dots per inch) and which color mode (1 bit through 24-bit) is available on each monitor and either use the built-in graphics of the Mac or use customized, write-to-each-screen graphics, to implement whatever drawing that you want. As an example of how backwards compatible Macintoshes programs (such as games) can be, there is a simple, shareware arcade game written almost completely in 68000 assembly language, that draws directly to the video-memory, which runs just fine in the original color Mac ii, as well as on the PowerMacintosh 8100/110. One can even use the exceedingly accurate Time Manager calls in the API to time whether your custom blitter is faster or Apple's blitter (CopyBits) and decide which to use, depending on whether accelerator video cards are installed or not. 3) Video modes are more standardized on the PC's than on Macs. Aside from the black & white only Macs (and even the SE/30 has the capability to handle color), ALL Macs use the same video modes. EVERY SINGLE ONE OF THE COLOR-CAPABLE MACS EVER MADE USES THE SAME VIDEO MODES, REGARDLESS OF WHAT KIND OF VIDEO CARD IS INSTALLED. Period. The modes are: 1 bit, 2-bit, 4-bit, 8-bit, 15-bit, 32-bit colors available in a program-accessible combination on each of the 6 monitors that a Mac can handle. The total number of pixels that a monitor or combination of monitors can have is 32,000 pixels horizontally and 32,000 pixels vertically. The user can use the control panels to arrange the monitors into a virtual screen that is of any shape at all, as long as every monitor is touching at least one other monitor at at least one point (you can arrange them in a diagonal with each monitor touching the upper right-hand cornder of the monitor below it, for instance). A standard (even Microsoft Word/Excel) business app can then use the built-in graphics to stretch a window to cover all the screens, although parts of the window may not show if the arrangement of the monitors isn't rectangular. A game programmer can elect to use custom-blitters to each monitor, or to use the built-in CopyBits blitter (similar to, but FAR, FAR, FAR, FAR more sophisticated than, WinG). As I said earlier, you can use 20-microsecond-resolution timeing to determine various issues, like whether to use standard API calls (in the case of an accelerator video card) or your own custom-blitters. A programmer can elect to use only one monitor, or to request which monitor should be used for what, or determine what the programmer thinks would be best. Programmers can also change the number of colors available, on-the-fly, while the program is running, in order to get the fastest possible performance. 4) PC's have a more standard sound I/O. Of all of the misconceptions stated, this is probably the least forgivable: The original Macintosh, presented to the public in 1984, had 8-bit mono sound that was capable of generating text-to-speech via software. This has improved over the years, but the API has been backwards compatible with almost every Mac (1985 on) ever built. With the advent of Sound Manager 3.0, EVERY Macintosh since 1985 can play 8-bit and 16-bit sounds, even if only an 8-bit sound chip is available, as the OS's sound software will convert on-the-fly, when needed. As well, Sound Manager 3.0 allows the addition of high-end sound cards that can (and do) make use of the same API as the built-in sound, so that your little 8-bit sound chip on the Mac ii can be transparently replaced by the most expensive MIDI card that money can buy, and most games will then use the MIDI card to produce the sound fx of the game. With the advent of QuickTime 2.0, software (or hardware) generated MIDI instruments are available to all 1985 and beyond Macs (95% of them, in other words), which will allow games and multi-media presentations to use MIDI in a standardized way. Look at the size of the Music file for the game Marathon for an idea of what this means: 250K of MIDI sound tracks results in nearly continuos music for 27 levels. On the other hand, the various beeps, grunts and gun-fire sounds of the game take up ~ 1 megabyte. 5) the installed base of the Mac just doesn't make it worthwhile to develop for games. Stuff about needing to have "emulation modes" for PowerMacs, etc. Gads. 85% of the operating system on a PowerMac is emulated using a 68020 emulator, and you worry about emulation modes being needed? Most new games and business apps are "fat" -that is, they contain complete 680x0 code for older Macs and complete PowerPC code for PowerMacs. The operating system uses the appropriate code at run-time. This holds true, even when running a "fat" program on a Mac Plus under System 6 that was built 10 years ago. If, by accident, you insert a PowerPC-only application in that Mac Plus, programmers know to have a tiny 68K application "embedded" in the PowerPC program that will run a special message saying "PowerPC-only, sorry." And as for the installed-base comment, Marathon runs on virtually all color-capable Macs, save the very slowest and provides numerous options for optimization to allow it to run at playable speeds on those that it will run on. On the slowest Macs, it requires much crippling, but on the fastest of the PowerMacs, it can do texturemapping with 16 million colors for the shading. 6) The rest of the article is just blathering with no knowledge of the subject, IMHO. Michael Lewchuk (lewchuk@cs.ualberta.ca) wrote: :I guess developers consider one aspect: "how much money will I make if I :develop game X for platform Y?", or "Is it profitable to write for or port :to platform Y given game X on machine Z?". :As far as I can tell, the difference between Mac and PC platforms is that :PCs are designed to be backwards compatible. I don't know if Macs are, but :with the differences in graphics that I've seen I can't see how they could be :easily compatible, particularly for graphics-intensive games. :So what we have is the difference between all the 386s, 486s, and 586s sold :(if it comes with a slowdown feature if it's realtime) and all of the Apples :you can get one game to run on. PCs all have relatively standard video modes :sound cards, and such, so if you can get a bunch of drivers working for these, : you've got it made. :So, to develop something for Apples, you must recover your costs from a bunch :of computers which can run your software, however restrictive a group this is. :With PCs, there is such a HUGE market, particularly if you think back to the :now obsolete 386s (or even sillier, the 286s) that it is likely your loss, if :any, will be cushioned by the sheer number of consumers, at least some of which :will buy your product. To make fruit, er, Apples, more attractive for :software developers, come up with a relatively standard instruction set and :graphics modes, or emulation programs (eg. turn your PowerPC into a Mac Plus). :It's not that it's not profitable to make something for Mac users. It may :or may not be. It's just that it's likely to be far more profitable to do :it for PCs because of the simple fact that you can develop for 50% of the PC :users much more easily than 50% of Apple users. The market develops with :shares according to the needs of each. Since there are less Apple users, and :with more specific needs in terms of CPU, graphics, etc., there will be a :smaller, more separated market than "wordprocessing for Windows" programs. : Michael Lewchuk : lewchuk@cs.UAlberta.CA -- ------------------------------------------------------------------------------- Lawson English __ __ ____ ___ ___ ____ english@primenet.com /__)/__) / / / / /_ /\ / /_ / / / \ / / / / /__ / \/ /___ / -------------------------------------------------------------------------------