NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/mac/hardware/26938

Text File | 1993-01-26 | 3.9 KB | 71 lines

Newsgroups: comp.sys.mac.hardware
Path: sparky!uunet!mcsun!sunic!kitten.umdc.umu.se!cs.umu.se!christer
From: [e-mail] (Christer Ericson)
Subject: Re: Street Fighter
Message-ID: <[e-mail]>
Followup-To: comp.sys.mac.programmer
Sender: [e-mail] (News Administrator)
Organization: Dep. of Info.Proc, Umea Univ., Sweden
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 26 Jan 1993 12:07:58 GMT
Lines: 58

In <[e-mail]> [e-mail] (Juri Munkki) writes:
>[...]
>Give me a few good examples why the OS would be in the way of writing
>game software? (Especially something as trivial as Street Fighter.) The
>only thing that I can think of is that the Sound Manager is not optimal
>for arcade games, but I don't think anyone would want to support the
>increasing number of different sound hardware implementations (at least
>four right now).
>[...]

Juri, I really respect your opinions on most matters, but this time I
think you're on thin ice. How can you categorize Street Fighter II as a
trivial game to write? Have you seen the game? You know as well as I do that
the Mac has no hardware support whatsoever for scrolling the screen, so in
order to have even a non-parallax version of the SFII background the whole
screen would have to be refreshed, in addition to which the two _quite_
large fighters (and eventual fireballs) would have to be drawn to the screen
as well. Just refreshing a whole screen in 256 colors on a LC would make for
a rather pitiful frame rate -- or do you suggest that the game would be for
Quadras only?

SFII aside, there are several ways in which the OS is in the way of writing
CPU-intensive game software (which I consider SFII to be, as stated above):

Interrupts. To get maximum performance, all interrupts should be disabled.
Unfortunately, things pretty much stop working when all interrupts are
disabled, and there is no way to enable/disable just some of the interrupts.
Eg, on an SE the mouse routines has to be disabled otherwise movement of
the mouse will interfer with the sound routines, with horrible sparkling
sounds as a result. This is possible to circumvent by mucking with the
low-mem global jCrsrTask and by writing a custom sound routine, ie by
bypassing the OS. Also, by replacing the ADB-driver lots of extra CPU-time
can be gained. Again, this involves working against the OS.

On the low-end machines (ie Plus, SE, and Classic) it has been possible to
gain extra performance by using the alternate screen buffer, but with
System 7.1 it is _no_longer_possible_ to use the alternate screen buffer
since System 7.1 allocates it during boot time. Not only is it impossible
to have an INIT which reserves the second page, it is also impossible
to write a MacsBug replacement with allocates the second page, because it
has already been allocated by the system at that stage -- but it is also
impossible to reserve the alternate screen buffer by setting the "reserve
second page" flag in the boot block, because System 7.1 _doesn't_ respect
that flag either! This means that a special start-up disk has to be made
in order to utilize the alternative screen buffer, in order to gain up to
50% increase in game performance (depending on how the game works). And
no, it is not possible to use the second buffer anyway, because it could
very well be that (in the future) the system will put an interrupt routine
there, and as argued above, the interrupts cannot be completely disabled.

Really, when optimal performance is needed, the OS is very much in the
way. And with _morons_ at Apple making utterly _stupid_ decisions like
not making the alternative screen buffer available under System 7.1, the
OS will only get more and more in the way in the future.


Christer Ericson --- Internet: [e-mail] --- tel: [phone]
Department of Computer Science, University of Umea, S-90187 UMEA, SWEDEN