bernard@boulder.Colorado.EDU (Bernie Bernstein) (01/30/89)
I think I remember seeing an answer to this a while ago but at the
time I didn't have a Mac II. So here it is again.
What does one need to do in order to get RISK to run on a Mac II.
I downloaded it from sumex and it runs for a few minutes and then
on some operations it just exits. No warning nor chance to save
the game.
Thanks
o, ,, , | Bernie Bernstein | , ,,
L>O/ \,/ \ ,| University of Colorado at boulder |/ \,,/ \
O./ ' / . `, / | office: (303) 492-1218 | / ` \ ,.
,/ / , ' | email: bernard@boulder.colorado.edu | / '' \bernard@boulder.Colorado.EDU (Bernie Bernstein) (02/02/89)
A few days ago I asked for the patch to get Risk to work on the
Mac II. I got several responses about it and letters from others
who wanted to know the same info. Here is an excerpt from the
letter I received from Jacob Ben-david Zimmerman.
>From: zimerman@phoenix.Princeton.EDU (Jacob Ben-david Zimmerman)
Article 13733 of comp.sys.mac:
Path: agate!ucbvax!ucsd!sdcsvax!ucsdhub!esosun!seismo!uunet!portal!cup.portal.com!Jerry_Geronimo_Whitnell
From: Jerry_Geronimo_Whitnell@cup.portal.com
Subject: Re: Risk game
Date: 6 Feb 88 06:14:23 GMT
Organization: The Portal System (TM)
A little work with TMON tracked down the problem. It is using the
Window Managers own port to draw the map. To do draw any other
windows, it saves away the bit map. The problem is, it is using
GetWMgrPort to get the port to figure out the size and Apple, in it's
great wisdom, change the definition of what GetWMgrPort returns (used
to be a GrafPort, now a CGrafPort). So Risk calculates a random value
for the size of the port, tries to allocate that much memory and exits
when it can (not very good programming style :-)
So, here is a patch to get around the little problem:
Offset $680E (Block $34, offset $e)
was: 3029 0006 C1E8 000C 48C0
to: 303C 1000 C1FC 0156 4E71 if 256 colors
to: 303c 0800 C1FC 0156 4E71 if 16 colors
to: 303C 0400 C1FC 0156 4E71 if 4 colors
to: 303C 0200 C1FC 0156 4E71 if 2 colors
Pick the number of colors you normally run the game at and apply the
above patch using FEdit or ResEdit. All this does is ignore the
returned GrafPort and calculate the values based on built in
constants. It appears to work fine with these patches applied, but
caveat emptor :-). Be sure to apply these to a backup copy, not your
original.
Jerry Whitnell
Thanks Jacob.
o, ,, , | Bernie Bernstein | , ,,
L>O/ \,/ \ ,| University of Colorado at boulder |/ \,,/ \
O./ ' / . `, / | office: (303) 492-1218 | / ` \ ,.
,/ / , ' | email: bernard@boulder.colorado.edu | / '' \lsr@Apple.COM (Larry Rosenstein) (02/03/89)
In article <6326@boulder.Colorado.EDU> bernard@boulder.Colorado.EDU (Bernie Bernstein) writes: >who wanted to know the same info. Here is an excerpt from the >letter I received > > From: Jerry_Geronimo_Whitnell@cup.portal.com > > windows, it saves away the bit map. The problem is, it is using > GetWMgrPort to get the port to figure out the size and Apple, in it's > great wisdom, change the definition of what GetWMgrPort returns (used > to be a GrafPort, now a CGrafPort). So Risk calculates a random value It's time again to defend the honor of the System Software engineers. :-) Everytime this question is asked, someone comes up with the same message, which gives the proper patches for the wrong reasons. The problem is that RISK assumes that the product of the screen width and the row bytes will be less than 32767. (It sign extends the product.) On a Mac II that's not the case. GetWMgrPort returns the same thing on a Mac II as on other Macs. Also, it is not necessary to apply a different patch depending on your screen depth. RISK doesn't use color, so it only needs a 2-bit deep offscreen buffer the size of the original Mac screen. So you might as well apply the 2 color patch to save heap space. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr