[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Escape from the Homebrew Computer Club goes ProDOS

David Schmenk wrote:

Michael J. Mahon wrote:


David Schmenk wrote:


Tristan Mumford wrote:


David Schmenk wrote:


I hacked the loader to use ProDOS MLI calls in order to run HBCC under
ProDOS (and thus CFFAs and hard disks). It uses the exact same binaries as version 1.2. I added a tools directory and source directory for fun.
Just out of curiosity, when it runs on something accelerated, e.g. a IIgs at full speed or something with a Zip Chip etc. does it run faster or with 
a higher framerate?

Tristan.
It does run faster, but the joystick code whacks out. If your accelerator can slow down during joystick address fetches, it should function OK. You can disable the joystick with the J key (CAPS LOCK) and use the keyboard controls. However, the timing is based off a 1 MHz processor, so everything gets accelerated, including the movement of bad guys and time. It runs at something like 200 Hz on my 9 MHz GS. Kinda useless. There really isn't any generic mechanism on the Apple II to establish a consistent timebase. If everyone had a mouse card it would solve that problem, but not everyone (or every Apple II) does. 


Actually, for the //e and later machines, there is the possibility of
establishing the clock rate of the machine (or emulator) by polling
the VBL level, which pulses every 60th of a second of real time.

Once the clock rate is established, the progression of game time
can be set to a standard rate, independent of frame rate.
Yes, that was the idea with the mouse card as well. Neither is generic across all Apple II models, and to actually implement the logic would require me to write more code. Also, there is still the problem with the joystick code and some accelerators. It's easier for me to just say "run at 1 MHz" :-) 

Believe me, I understand!  "One more option" is the bane of all
programmers.  ;-)

And adding code to check which machine the program is running on,
while straightforward, opens lots of "option" doors.  ;-)

WRT joysticks and accelerators, I thought that the most popular ones
all accomodated slowing down while reading the joystick, making the
exceptions truly exceptional.  Certainly Zips do, but I don't know
about TransWarps.

Requiring a user with an "unusual" accelerator to disable it doesn't
seem like a weird restriction, and it would allow much smoother
animation for most accelerator users without changing the play speed
of the game.

But, as I said, I understand your reluctance to "open the box" and
start modifying the game code.
The one thing that might get me to spend some more time with this over the winter would be a NadaNet based multiplayer. Hmmm. How to make the joystick and NadaNet work together? 

That would work fine, since NadaNet requests don't time out until a
target machine has not responded for over three seconds (and that is
a settable parameter).  Joystick readings take only a few milliseconds,
just like NadaNet requests.  ;-)

When a request is not acknowledged, the requesting machine backs off for
about 20 milliseconds, then tries again, so there is a "responsiveness"
penalty of about 20 milliseconds for the target machine not "listening"
momentarily.  For moving around in a room, that shouldn't be too bad.

Another approach would be for all "player" machines to send their
position/action updates to a central machine, and to request state
about their current room from that machine.  This would require one
"server" machine, but it would provide consolidated information to
each player machine when it requested it, which would stave of the
n-squared problem of machines communicating with each other (which
might be an issue for n greater than three).

Of course, there's still the fact that NadaNet requires annunciators,
and the IIc and IIc+ don't have them...

-michael

NadaNet file server for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."