Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!stanford.edu!agate!garnet.berkeley.edu!deadman From: deadman@garnet.berkeley.edu (Ben Haller) Newsgroups: comp.sys.mac.programmer Subject: Re: Game input -- Bypassing GetNextEvent Message-ID: <1991May4.224842.11140@agate.berkeley.edu> Date: 4 May 91 22:48:42 GMT References: <12888@pt.cs.cmu.edu> Sender: root@agate.berkeley.edu (Charlie Root) Organization: Stick Software Lines: 44 In article d88-jwa@byse.nada.kth.se (Jon W{tte) writes: >In article <> hairston@henry.ece.cmu.edu (David Hairston) writes: > well, my gut response is that action games should still be cooperative. > if you find that you cannot run action game x because you're doing too > much background processing then the user should voluntarily stop the bg > applications. i think this is preferred to the alternative of having > action game x unilaterally stop the bg apps. cooperative multitasking > requires cooperation! > >The problem with this is that WNE is pretty slow even if there are no >other background apps that want time. There's a lot of overhead >involved, and to get decent speed on a classic or LC... Also, MultiFinder is a little unpredictable. It seems to just go out to lunch occasionally, and it changes its mind about how much time to give to the foreground app, *even* when that's the only app running (i.e. the Finder). Also, people do strange and time consuming things in the background, so you don't want to give them time. For instance the System 7.0 Finder appears to do several SetTrapAddress calls (believe it or not!) every time through its event loop, as well as a SetCursor, etc. Even if these things are patched out by MultiFinder, they do take time. My personal policy is to call GetOSEvent to get keyboard events and such, and munge with the low-memory globals to get the mouse position (ever disassembled GetMouse() - under System 7.0, my god what a mess, it has a come-from test and everything...!) Never call SystemTask unless you want little menu bar clocks, screen savers, etc. punching through your pretty full-screen display. As far as getting cursor information *directly*, yes, you could patch the cursor vectors, but these are not guaranteed to change, to say the least. Still I know I guy who has done it so many times he doesn't even blink anymore (actually he *does* blink, just not at that...) Finally, why call GetKeys? It is more compatable and all, but if we're interested in raw speed, why not? And besides that rather stupid excuse, a (possibly) more intelligent excuse is that so many people do it already that Apple would never break it. And if they did break it, to support bigger keyboards, 2-byte characters, etc., I can't see how they would avoid breaking GetKeys anyway. Actually, I'm being a bit of a Devil's Advocate here, since I firmly believe that access routines should always be called because then one can patch the access routines... :-> But since patching for such purposes is generally considered *worse* than using low-memory globals, why call GetKeys? -Ben Haller (deadman@garnet.berkeley.edu) "Whatever" - Anon.