Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!netserv2!deven From: deven@rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga Subject: Re: Game vs Multitasking Message-ID: Date: 7 Jun 90 11:17:47 GMT References: <9006010158.AA01507@jade.berkeley.edu> <18302@well.sf.ca.us> <18368@well.sf.ca.us> Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 60 In-Reply-To: farren@well.sf.ca.us's message of 6 Jun 90 07:41:31 GMT I wrote: Deven> The key is to think ahead. If you can run an application on a Deven> 512K machine, all the better. [what about the original 256K Deven> A1000? ;-)] However, it is a poor idea indeed to *assume* the Deven> configuration of the least common denominator... In a few Deven> years, you can be pretty sure a 512K A500 will NOT be the most Deven> common configuration, just as the old 256K A1000 is by no means Deven> common now. On 6 Jun 90 07:41:31 GMT, farren@well.sf.ca.us (Mike Farren) said: Mike> You *assume* that you will be running on a minimal Mike> configuration. You then *check* to see if your assumptions are Mike> wrong. Where you find extra capability, you can use it, but Mike> making the assumption that those extra features will be there is Mike> dumb - unless your application specifically demands it. [below, "you" == any developer (game developers, particularly in this instance, but all really) and "user" or "he" == the user of the game or application, of whatever gender.] What I meant was not to do stupid things based on the (questionable) assumption of running on a minimal configuration. That is, don't flush loaded bitmaps and reload from floppy if there's enough RAM to hold them all in memory, don't take over the machine based on the assumption that it's the ONLY way to get the needed memory, don't use instructions which fail on an '020, [e.g. MOVE SR, instead of calling GetCC()...] and so on. If you're running on a minimal-configuration system, THEN take measures if you must. If you really need all the memory on a 512K machine and absolutely MUST take out the operating system to run at all, then make the program CHECK at startup to see if there's less available RAM than the program needs, and if (and only if) there isn't enough memory, ask the user whether to toast the system to run the game, or not. It is important to offer the user the option to abort. They might want to save something they're working on or whatever, and then rerun the game, letting it trash the system. But it is a bad idea to assume you know better than the user what he wants to do with his system. You don't know what the user may be doing. Second-guessing will result in numerous situations where you chose wrong. Much better is to give intelligent *defaults*, so if the user is clueless, you can guide him, but if the user knows what he wants to do, stand aside and let him. If you are convinced that you need to disable multitasking for all possible speed, then give the user the choice of whether or not to disable multitasking, with the default being to disable it. But let the USER make the final decision. He knows his particular situation better than you do. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th St. Apt. 2, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.