Path: utzoo!attcan!uunet!cs.utexas.edu!ut-emx!walt.cc.utexas.edu!jonabbey From: jonabbey@walt.cc.utexas.edu (Jonathan Abbey) Newsgroups: comp.sys.amiga Subject: Re: Game vs Multitasking Keywords: Game Users Message-ID: <30941@ut-emx.UUCP> Date: 4 Jun 90 18:22:46 GMT References: <3871@darkstar.ucsc.edu> <9143@rouge.usl.edu> <3916@darkstar.ucsc.edu> <1031@mpirbn.UUCP> Sender: news@ut-emx.UUCP Reply-To: jonabbey@walt.cc.utexas.edu (Jonathan Abbey) Distribution: comp Organization: The University of Texas at Austin, Austin, Texas Lines: 29 In article <1031@mpirbn.UUCP> p554mve@mpirbn.UUCP (Michael van Elst) writes: > >The most time consuming task is the input.device (ala, Intuition()). >And more cycles may be eaten by interrupt code. But this not a cause for >trouble. I can go with this little speed penalty. > >-- >Michael van Elst >UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve >Internet: p554mve@mpirbn.mpifr-bonn.mpg.de > "A potential Snark may lurk in every tree." So what would you say to a game that inserts an input.device handler above intuition, and gobbles all input events? I'm working on a 3d modem maze game, and the current scenario entails the game taking ruthless control over the system by locking out intuition, but upon a left-amiga n, it releases the input.device, and meekly withdraws to a window on the workbench screen for purpose of monitoring serial port messages from other players. Would this be acceptable? I'm using frame buffering, so I can't work with an Intuition screen and get any reasonable speed, I fear.. Does 2.0 provide better support for people going directly to the view level? Jonathan Abbey (512) 926-5934 | Amiga Programmer Wanna-be jonabbey@ccwf.cc.utexas.edu bix: jonabbey +----------------------------- The University of Texas at Austin - CS Undergrad | Speaking for myself, at best