Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!kth.se!cyklop.nada.kth.se!news From: d88-jwa@byse.nada.kth.se (Jon W{tte) Newsgroups: comp.sys.mac.programmer Subject: Re: Game input -- Bypassing GetNextEvent Message-ID: Date: 2 May 91 08:43:06 GMT References: <10219@etsu.CMI.COM> <1991May1.030929.30240@kuhub.cc.ukans.edu> <12874@pt.cs.cmu.edu> Sender: news@nada.kth.se (Mr News) Organization: Royal Institute of Technology, Stockholm, Sweden Lines: 24 In-reply-to: hairston@henry.ece.cmu.edu's message of 1 May 91 19:39:14 GMT In article hairston@henry.ece.cmu.edu (David Hairston) writes: (Hi, Dave ! :-) just curious ... 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. I'm not sure how this affects speed, tho. i'm also assuming that your window will cover the WaitNextEvent will a) take time and b) let other program calculate in the background, even if no major context switch is made. The minor switch still takes time, since all lo-mem globals have to be shuffled. MBarHeight = saveMBH. the benefit here is that you allow background tasking by calling WNE regularly. so why not do it this way? Hey, they're talking action games... -- Jon W{tte h+@nada.kth.se - Power !