Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!henry.ece.cmu.edu!hairston From: hairston@henry.ece.cmu.edu (David Hairston) Newsgroups: comp.sys.mac.programmer Subject: Re: Game input -- Bypassing GetNextEvent Message-ID: <12888@pt.cs.cmu.edu> Date: 2 May 91 18:33:03 GMT References: <1991May1.030929.30240@kuhub.cc.ukans.edu> <12874@pt.cs.cmu.edu> Organization: Gaia II Lines: 29 [hairston@henry.ece.cmu.edu (David Hairston) writes:] [] why not make your app use a window that uses DBoxProc? this way you [] can use WNE to your hearts content since MultiFinder will not swap you [] out while the DBoxProc window is in front. [] ... [] MBarHeight = saveMBH. the benefit here is that you allow background [] tasking by calling WNE regularly. so why not do it this way? [d88-jwa@byse.nada.kth.se (Jon W{tte) writes:] [] (Hi, Dave ! :-) ummm, we have to stop meeting like this ... ;) [d88-jwa@byse.nada.kth.se (Jon W{tte) writes:] [] Hey, they're talking action games... 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! btw, an action game can determine if it is not running at a desirable rate and in the extreme could simply complain that the machine is too busy at the moment and "would you like to quit?" ... -dave- hairston@henry.ece.cmu.edu