brett@smosjc.UUCP (Brett Coon) (06/04/90)
>From: Tim Friest - Programmer/Analyst <uunet!cornellc.cit.cornell.edu!AXTBF%ALASKA.BITNET> >The point the people are making about games needing to multi-task is simply, >if I run the game without anything else running, it is exactly the same as >if the game took over the machine and didn't let me run anything else.... NO! For a program to allow multitasking, it has to be "nice". It must own and disown the system resources (esp. blitter) using OS calls, and do so often enough to allow other tasks a chance to use them. Depending on the program and the specific circumstances, this additional overhead could make a real difference in performance. And I'm not defending poor programming practices like skipping the OS altogether, either. The point is, if a program doesn't have to worry about giving any other programs use of the system resources, it can take control of them all, and not release control until it's finished. Whether it accesses them directly or through the OS is another issue. Personally, I agree that multitasking games are preferable to non-multitasking ones. And I don't feel that copy protection or programmer laziness are good reasons to abandon multitasking. But given the choice, I would always pick a good non-multitasking game over a poor multitasking one. So, while I think it's good to stress the importance of multitasking to the game programmers on the net, I also think there are some instances in which multitasking support isn't worth the price. Luckily, the price is small, so these instances SHOULD be rare. And games should DEFINITELY be HD installable.
davids@ucscb.UCSC.EDU (Dave Schreiber) (06/04/90)
In article <279@smosjc.UUCP> brett@smosjc.UUCP (Brett Coon) writes: >>From: Tim Friest - Programmer/Analyst <uunet!cornellc.cit.cornell.edu!AXTBF%ALASKA.BITNET> >>The point the people are making about games needing to multi-task is simply, >>if I run the game without anything else running, it is exactly the same as >>if the game took over the machine and didn't let me run anything else.... > >NO! For a program to allow multitasking, it has to be "nice". It must own >and disown the system resources (esp. blitter) using OS calls, and do so >often enough to allow other tasks a chance to use them. Depending on the Are you reading all of the original message? If the machine is in a state so that the game is going "without anything else running", then there won't be "other tasks" that demand system resources like the blitter. This seems fairly self-evident. [...] -- Dave Schreiber The blue leprechaun at davids@slugmail.ucsc.edu (prefered but flakey) or (not both) davids@ucscb.ucsc.edu "Coffee, Darling?"
nicthu@mcorp.UUCP (Nick "The Watchdog" Thurn) (06/05/90)
In article <4039@darkstar.ucsc.edu>, davids@ucscb.UCSC.EDU (Dave Schreiber) writes: > > In article <279@smosjc.UUCP> brett@smosjc.UUCP (Brett Coon) writes: > >>From: Tim Friest - Programmer/Analyst <uunet!cornellc.cit.cornell.edu!AXTBF%ALASKA.BITNET> > >>The point the people are making about games needing to multi-task is simply, > >>if I run the game without anything else running, it is exactly the same as > >>if the game took over the machine and didn't let me run anything else.... > > > >NO! For a program to allow multitasking, it has to be "nice". It must own > >and disown the system resources (esp. blitter) using OS calls, and do so > >often enough to allow other tasks a chance to use them. Depending on the > > Are you reading all of the original message? If the machine is in a state > so that the game is going "without anything else running", then there won't > be "other tasks" that demand system resources like the blitter. This > seems fairly self-evident. > But the program DOESN'T KNOW that nothing else is running, so it STILL has to check periodically, just as Brett says. The only way the program could know is "if the game took over the machine and didn't let" you "run anything else." In summary: "The point people are making" stated by Tim is wrong. Brett's statement is correct. Dave's statement is _non sequitur_. ---------- Nick Thurn cis.ohio-state.edu!mcorp!nicthu Symix Computer Systems Inc. nicthu@mcorp.UUCP Columbus, Ohio
brett@smosjc.UUCP (Brett Coon) (06/05/90)
>>In article <279@smosjc.UUCP> brett@smosjc.UUCP (Brett Coon) writes: >>NO! For a program to allow multitasking, it has to be "nice". It must own >>and disown the system resources (esp. blitter) using OS calls, and do so >>often enough to allow other tasks a chance to use them. Depending on the >From: Dave Schreiber <uunet!ucscb.ucsc.edu!davids> >Are you reading all of the original message? If the machine is in a state >so that the game is going "without anything else running", then there won't >be "other tasks" that demand system resources like the blitter. This >seems fairly self-evident. Yes, but the rule on the Amiga is that as soon as a program isn't using a limited resource like the blitter, it tells the operating system this to allow other tasks (if there are any) a chance to use the resource. Then, the next time the program wants the resource, it must request it from the OS and, if anything else is using it, wait for it to be free. Even if no other programs are using any of these resources, the game must still suffer the additional overhead of communicating with the operating system to learn this fact. -- |Brett Coon | uunet!smosjc!brett | |S-MOS Systems, Inc. | "You like 'em, anchovies?" | |San Jose, CA | -Runaway Train |
vilkas@ultima.cs.uts.oz (Iron Wolf) (06/05/90)
davids@ucscb.UCSC.EDU (Dave Schreiber) writes: >In article <279@smosjc.UUCP> brett@smosjc.UUCP (Brett Coon) writes: >>>From: Tim Friest - Programmer/Analyst <uunet!cornellc.cit.cornell.edu!AXTBF%ALASKA.BITNET> >>>The point the people are making about games needing to multi-task is simply, >>>if I run the game without anything else running, it is exactly the same as >>>if the game took over the machine and didn't let me run anything else.... >> >>NO! For a program to allow multitasking, it has to be "nice". It must own >>and disown the system resources (esp. blitter) using OS calls, and do so >>often enough to allow other tasks a chance to use them. Depending on the >Are you reading all of the original message? If the machine is in a state >so that the game is going "without anything else running", then there won't >be "other tasks" that demand system resources like the blitter. This >seems fairly self-evident. But even when your task is the only one running, there are other tasks that are started by amigados: The mounted devices have processes (mostly dormant so they dont really count) Cli or Workbench (cli transfers control to the program so it doesnt make a huge difference) Intuition itself. OF the above, intuition and workbench will take a fair amount time up, especially intuition, (which will in turn access the device processes for mouse moves, etc) So, even when you are running only one game, the system is running at least one of its own tasks, and, I believe, at a considerably higher priority! What is more, is that all of these OS tasks and the like take up ram space which a big game that requires speed could use for faster (but larger) code or data storage. There! now that might stir someone up a bit! Iron Wolf
laba-1ei@e260-3c.berkeley.edu (Joseph Chung) (06/05/90)
In article <4039@darkstar.ucsc.edu> davids@ucscb.UCSC.EDU (Dave Schreiber) writes: >>NO! For a program to allow multitasking, it has to be "nice". It must own >>and disown the system resources (esp. blitter) using OS calls, and do so >>often enough to allow other tasks a chance to use them. Depending on the > >Are you reading all of the original message? If the machine is in a state >so that the game is going "without anything else running", then there won't >be "other tasks" that demand system resources like the blitter. This >seems fairly self-evident. Hold on a minute. If I want to multitask, I must nicely ASK for resources to be given, therefore incurring an extra overhead. However, if I take over the machine, I TAKE whatever resources I want, bypassng the boss. I have a question here: Does WB count as a process/task? Cuz if it does, then exec must time-slice in order to share it with a running game. No matter how small that slice of time is, it is still taken; otherwise, how will WB know to respond when a mouse is clicked in its domain? -jc -- Joseph Chung == You can always find what you're not looking for! == laba-1ei@web.berkeley.edu
gilgalad@zip.eecs.umich.edu (Ralph Seguin) (06/05/90)
In article <1990Jun5.082227.29350@agate.berkeley.edu> laba-1ei@e260-3c (Joseph Chung) writes: >I have a question here: Does WB count as a process/task? Cuz if it does, >then exec must time-slice in order to share it with a running game. No >matter how small that slice of time is, it is still taken; otherwise, how >will WB know to respond when a mouse is clicked in its domain? > No. This is wrong. You should not make any assumptions as to how much a process is going to run. A process may be blocking, and thus will never use any CPU time until it is placed back on the ready queue. Please learn about scheduling. Now for my two cents: I absolutely refuse to buy a game that does not work on a hard drive, and does not work on 030. I would definitely prefer it to multitask and release all the resources to the system. All this nonsense about multitasking taking up too much processor time is just that: nonsense. My bet is that the people taking this standpoint really don't know what they are talking about, and furthremore cannot program well either. It doesn't take any more effort to program by C= guidelines, and if you follow them, your game will work on any system. Going directly to hardware or ignoring the guidelines is much harder to debug, makes things incompatable, and basically junk in my opinion. You gain NO speed in ignoring the guidelines. Furthermore, you will NOT get my money! See ya, Ralph >-jc > >-- >Joseph Chung >== You can always find what you're not looking for! == >laba-1ei@web.berkeley.edu gilgalad@dip.eecs.umich.edu gilgalad@zip.eecs.umich.edu gilgalad@caen.engin.umich.edu Ralph_Seguin@ub.cc.umich.edu gilgalad@sparky.eecs.umich.edu USER6TUN@UMICHUB.BITNET Ralph Seguin | In order to get infinitely many monkeys to type 565 South Zeeb Rd. | something that actually makes sense, you need to Ann Arbor, MI 48103 | have infinitely many monkey editors as well. (313) 662-1506
bjornk@bula.se (Bjorn Knutsson) (06/06/90)
In article <1990Jun5.082227.29350@agate.berkeley.edu> laba-1ei@e260-3c.berkeley.edu (Joseph Chung) writes: >In article <4039@darkstar.ucsc.edu> davids@ucscb.UCSC.EDU (Dave Schreiber) writes: >>>NO! For a program to allow multitasking, it has to be "nice". It must own >>>and disown the system resources (esp. blitter) using OS calls, and do so >>>often enough to allow other tasks a chance to use them. Depending on the >> >>Are you reading all of the original message? If the machine is in a state >>so that the game is going "without anything else running", then there won't >>be "other tasks" that demand system resources like the blitter. This >>seems fairly self-evident. > >Hold on a minute. If I want to multitask, I must nicely ASK for resources >to be given, therefore incurring an extra overhead. However, if I take over >the machine, I TAKE whatever resources I want, bypassng the boss. Yes, this is true. On the other hand you only have to allocate most resources once. The obvious exception being the blitter. Now, one solution to this is to simply allocate it and use it, but give it back whenever you don't need it for a while, as well as giving it back if the user signals (in some way) that he wants to access other screens. Now, I'm sure there are some shoot 'em ups that more or less requires continous use of the blitter, and I guess I can live with them allocating and using the blitter for longer (several seconds at a time) periods. But I'm equally sure that I would survive if they weren't quite as fast and didn't allocate the blitter for longer periods, if the programs didn't disturb the rest of my system. >I have a question here: Does WB count as a process/task? Cuz if it does, >then exec must time-slice in order to share it with a running game. No >matter how small that slice of time is, it is still taken; otherwise, how >will WB know to respond when a mouse is clicked in its domain? Well sort of, but what has WB to do with the mouse? WB is only waiting for a message from intuition and waiting consumes no time at all. If your programs wait for mouse events by busywaiting I suggest you reread your RKMs. >-jc > >-- >Joseph Chung >== You can always find what you're not looking for! == >laba-1ei@web.berkeley.edu --- Bjorn Knutsson / USENET: bjornk@bula.se or sunic!sics!bula!bjornk Stangholmsbacken 44 / Phone : +46-8-710 7223 S-127 40 SKARHOLMEN / "Oh dear, I think you'll find reality's on the S W E D E N / blink again." -- Marvin The Paranoid Android
davids@ucscb.UCSC.EDU (Dave Schreiber) (06/06/90)
In article <1990Jun5.082227.29350@agate.berkeley.edu> laba-1ei@e260-3c (Joseph Chung) writes: >In article <4039@darkstar.ucsc.edu> davids@ucscb.UCSC.EDU (Dave Schreiber) writes: >>>NO! For a program to allow multitasking, it has to be "nice". It must own >>>and disown the system resources (esp. blitter) using OS calls, and do so >>>often enough to allow other tasks a chance to use them. Depending on the >> >>Are you reading all of the original message? If the machine is in a state >>so that the game is going "without anything else running", then there won't >>be "other tasks" that demand system resources like the blitter. This >>seems fairly self-evident. > >Hold on a minute. If I want to multitask, I must nicely ASK for resources >to be given, therefore incurring an extra overhead. However, if I take over >the machine, I TAKE whatever resources I want, bypassng the boss. Hmmm. Perhaps someone from Commodore could answer this: how much overhead does the OwnBlitter() function take? Will there be a signifigant increase in speed if a program gets the blitter for the entire duration of the program, as oppossed to getting it, releasing it, getting it, etc. Another question: how many games actually need to run the blitter at full speed for the _entire_ duration of the program? It strikes me that most that make very heavy use of the blitter don't use it continuously: I can't really see StarGlider II (just to pick one at random, and yes I did see the message stating why the program shuts down the O.S.) needing full control of the blitter when all you're doing is sitting in one of those tunnels trying to decide which direction to go next. [...] >Joseph Chung -- Dave Schreiber The blue leprechaun at davids@slugmail.ucsc.edu (prefered but flakey) or (not both) davids@ucscb.ucsc.edu "Coffee, Darling?"
davids@ucscb.UCSC.EDU (Dave Schreiber) (06/06/90)
In article <17902@ultima.cs.uts.oz> vilkas@ultima.cs.uts.oz (Iron Wolf) writes: >davids@ucscb.UCSC.EDU (Dave Schreiber) writes: >>In article <279@smosjc.UUCP> brett@smosjc.UUCP (Brett Coon) writes: >>>>From: Tim Friest - Programmer/Analyst <uunet!cornellc.cit.cornell.edu!AXTBF%ALASKA.BITNET> >>>>The point the people are making about games needing to multi-task is simply, >>>>if I run the game without anything else running, it is exactly the same as >>>>if the game took over the machine and didn't let me run anything else.... >>>NO! For a program to allow multitasking, it has to be "nice". It must own >>>and disown the system resources (esp. blitter) using OS calls, and do so >>>often enough to allow other tasks a chance to use them. Depending on the >>Are you reading all of the original message? If the machine is in a state >>so that the game is going "without anything else running", then there won't >>be "other tasks" that demand system resources like the blitter. This >>seems fairly self-evident. >But even when your task is the only one running, there are other tasks that >are started by amigados: >The mounted devices have processes (mostly dormant so they dont really > count) >Cli or Workbench (cli transfers control to the program so it doesnt > make a huge difference) >Intuition itself. >OF the above,intuition and workbench will take a fair amount time up,especially >intuition,(which will in turn access the device processes for mouse moves, etc) Workbench sits dormant, as does the CLI. Intuition processes input, so as long as the user doesn't type, move the mouse, eject disks, etc. Intuition will barely do anything (the occasional Intuitick being the exception). Also please note (I guess I should have made this more clear in my previous message) that while other system tasks are running, they do not generally use the blitter (unless the user is moving windows around, etc., in which case it isn't the program's fault). >So, even when you are running only one game, the system is running at least one >of its own tasks, and, I believe, at a considerably higher priority! No, the OS has tasks present, but not actually taking up the CPU for the most part. [...] -- Dave Schreiber The blue leprechaun at davids@slugmail.ucsc.edu (prefered but flakey) or (not both) davids@ucscb.ucsc.edu "Coffee, Darling?"
phorgan@cup.portal.com (Patrick John Horgan) (06/06/90)
In article <1990Jun5.082227.29350@agate.berkeley.edu> laba-1ei@e260-3c (Joseph Chung) writes: >I have a question here: Does WB count as a process/task? Cuz if it does, >then exec must time-slice in order to share it with a running game. No >matter how small that slice of time is, it is still taken; otherwise, how >will WB know to respond when a mouse is clicked in its domain? > This isn't true at all! The Workbench would (I assume), wait for a signal. This takes it off the ready-to-run queue and puts it on the waiting-for-re- sources queue. It won't get any slices until it gets signaled which will cause the exec to move it to the ready to run queue where it can get dispatched. It's true that there is some overhead from the exec, but if you don't busy wait it's inconsequential compared to something so common as slightly unoptimized code. Let's have a big usenet cheer for Carl Sassenrath for a job well done:) Patrick Horgan phorgan@cup.portal.com
cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) (06/06/90)
In article <1990Jun5.082227.29350@agate.berkeley.edu> (Joseph Chung) writes: >Hold on a minute. If I want to multitask, I must nicely ASK for resources >to be given, therefore incurring an extra overhead. However, if I take over >the machine, I TAKE whatever resources I want, bypassng the boss. Joseph, you have some fundamental misunderstandings here. Take a moment and think about this. It's true that you have to execute an additional 50 or 100 instructions _once_ to ask nicely for a resource for a game. However, once your game is up and running, you won't be asking anymore and won't be incurring any more "overhead" further, a couple of hundred, even a couple of thousand additional instructions on startup will occur faster than you can click the mouse or even notice that they have occured. Again, once you have the resources such as memory, full mouse/joystick ownership, disk drive ownership, etc. No one else will get those resources and you won't have to ask for them again. They are yours to abuse until you release them. >I have a question here: Does WB count as a process/task? Cuz if it does, >then exec must time-slice in order to share it with a running game. No >matter how small that slice of time is, it is still taken; otherwise, how >will WB know to respond when a mouse is clicked in its domain? Your question should have pointed out your blind spot here. Yes, the workbench is a process. However, when you own the mouse Workbench (and everyone else for that matter) will never get a mouse click unless your program decides to let it see one. A process that is idle like this (waiting on an event that your game won't allow to happen) takes NO time/overhead. The scheduler looks at the ready to run queue, and the highest priority/only thing on it will be your game. Everything else is waiting on a resource that you have correctly requested and now own. If you didn't correctly request them, the other tasks might not realize that you own them (most probably) and then they _would_ think they were ready to run and this would incur overhead. The presence of other tasks will have no more of an effect on your "time" than the existence of your data in memory has on slowing something down. (ie NO EFFECT) If you _want_ the trackdisk.device task to get some time so that it can load a file _for_ your game, you can release the disk drive and ask for a file. Then and only then will it use any cycles. The key here is that "multitasking friendly" doesn't mean you necessarily have to allow other tasks to run while you do, after all you really do "own" the machine and the OS will give it all to you if you ask nicely. To be friendly, you simply have to be willing to let the user ask your program to give back some resources to the other tasks, which your game can do for the user on a provisional basis. When the user is done and tells you game or whatever that they are done, the game can go out and take those resources back! -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: <none> Internet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "I tell you this parrot is bleeding deceased!"
sjorr@cbmtor.UUCP (Stephen Orr) (06/09/90)
I would like to point out at this point that we all live in a capitalist world, and this discussion of Multitasking vs. non-Multitasking games is quite simple to resolve. I personally am a developer on the Amiga, and see the merits of games which will multitask. I also enjoy F18, and others which don't. Each has it's place on my system, some I use while downloading/uploading. Some I use just to have fun, I'll let you guess which is which. In the long run however, if non-Multitasking games were SOOO bad, then the companies that insist on producing then would go bankrupt, and it doesn't look like they are. In the end if YOU don't like a non-multitasking game then don't buy it. Personally I don't play an awful lot of games, and base my purchases purely on the entertainment, and quality with which the program succeeds in whatever it was designed to do. If that means taking over the machine to fly a jet fight at god-forsaken speeds, and I choose to buy it then fine. More important than the multitasking issue is the CPU issue. Programs which force me to boot with both fingers on the mouse, and don't allow me to play with the 030, do anoy me. At least F18 doesn't have this problem. Stephen Orr SandIsoft ---------------------------------------------------------------------------- Any association between me and Commodore is purely a coincidence of me owning an Amiga, I have nothing to do with Commodore Canada, and my opinions are those of my employer...ie: I'm self employed ----------------------------------------------------------------------------
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (06/10/90)
In <121@cbmtor.UUCP>, sjorr@cbmtor.UUCP (Stephen Orr) writes: >I would like to point out at this point that we all live in a capitalist >world, and this discussion of Multitasking vs. non-Multitasking games is >quite simple to resolve. True. >In the long run however, if non-Multitasking games were SOOO bad, then the >companies that insist on producing then would go bankrupt, and it doesn't >look like they are. Well, so far, there hasn't been much choice. Should game designers start following the lead of the folks that did PocoMan, perhaps we will see a move by the purchasers toward these types of programs. It's not overly meaningful to say that the purchasers have decided they find the current situation acceptable when there are no (or few) alternatives. >In the end if YOU don't like a non-multitasking game then don't buy it. Thanks you. I won't, and don't. >Personally I don't play an awful lot of games, and base my purchases >purely on the entertainment, and quality with which the program succeeds >in whatever it was designed to do. I base it on that too, it's just that the entertainment value is severely decreased when I think of what is happening to my machine. Knowing that a game has crashed my machine as soon as I start it is not helping me have warm thoughts about it. All it takes is one time that I can't pause the game, flip to a CLI, and find a phone number in my phonelist, to make me say 'never again'. Capitalism at work. >More important than the multitasking issue is the CPU issue. Programs which >force me to boot with both fingers on the mouse, and don't allow me to play >with the 030, do anoy me. At least F18 doesn't have this problem. I'll go along with that one 100%. -larry -- The raytracer of justice recurses slowly, but it renders exceedingly fine. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+