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. <sheesh>

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                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
-------------------------------------------------------------------------------
