Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!cbmehq!cbmdeo!jsmami!jsmoller From: jsmoller@jsmami.UUCP (Jesper Steen Moller) Newsgroups: comp.sys.amiga.programmer Subject: Re: CPU usage [Was: Lemmings - ....] Message-ID: <18f2e010.ARN12a2@jsmami.UUCP> Date: 7 Apr 91 13:29:56 GMT References: <23788@well.sf.ca.us> <23837@well.sf.ca.us> <781@tnc.UUCP> <884@cns.SanDiego.NCR.COM> <1991Apr5.232419.23297@starnet.uucp> Reply-To: cbmehq!cbmdeo!jsmami!jsmoller (Jesper S. Moller) Followup-To: comp.sys.amiga.programmer Organization: Danish SofTech Lines: 34 In article <1991Apr5.232419.23297@starnet.uucp>, Stephan Schaem writes: > We those kind of memory usage you do it for games, and game only. > And when you have a speady rate you DO NOT WANT IT TO GO FASTER. > So you syncronise to WAIT.So 32 bit memory is nothing more than memory > at that point. Ever played Indianapolis 500? Slow machines - choose a less detailed screen. Fast machines (32 bit processors and RAM or even 16-bit fast RAM) choose some more details. Note the ultra-smooth update on the A3000. > And if a game is designed for 512k it will use 512K, the extra memory > will not be used for serious game desing.More for buffer or save the > system:-) Indianapolis 500 is a very fine game indeed. I really like it, even though it doesn't multitask. It could have. > But if you make a multitasking game its totaly diferent, because here > you care about how mutch cycle you leave to the OS... Aha - you don't know about interrupts and task signals at all? > Anyway I'm saying that but almost all aplication dont care for the > above. If you'd quote someone it would be a bit easier to understand you. Or just change the subject line to something more convenient... /Jesper -- __ Jesper Steen Moller /// VOICE: +45 31 62 46 45 Maglemosevej 52 __ /// USENET: cbmehq!cbmdeo!jsmoller DK-2920 Charl \\\/// FIDONET: 2:231/84.45 Denmark \XX/