NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/3713

Text File | 1996-08-05 | 2.9 KB | 60 lines

Newsgroups: comp.sys.amiga.programmer
Path: newshost.grace.cri.nz!maths!peterm
From: [e-mail] (Peter McGavin)
Subject: Re: Demo/game to OS frien
Message-ID: <[e-mail]>
Date: 21 Feb 1996 10:57:37 GMT
Distribution: inet
References: <4g4eaa$[e-mail]> <[e-mail]>
Organization: Industrial Research Ltd
In-reply-to: [e-mail]'s message of 20 Feb 1996 03:42:43 GMT

[e-mail] (Accolyte) writes:
>> It depends..  If you have a framerate of 50fps, wiggling the mouse will
>> make the whole thing jerk down to 25fps.  At least it did the last time
>> I checked.
>
>Same here. Another testament to the overhead are the demos written for 1.3
>that used system interrupts, and jump out of frame with 2.0+ because (and
>only because) the system takes more time.. I must be a considerable amount
>then.

This is not a reason for killing the entire OS.  The performance hit
when the mouse moves comes from Intuition and the console.device.
That is easily eliminated, without killing the entire OS, by
installing an input-handler as described in the input.device chapter
of the Devices RKM.  This has the added advantage of providing highly
efficient keyboard and mouse input in exactly the same format as
current raw hardware in a way that is promised to work on all existing
and future Amigas.  This includes the problematic A3000 keyboard,
CD32s with PC keyboards, homemade keyboards, serial mice, etc.  And it
prevents the user flipping screens giving the illusion of
single-tasking without disabling network play or continuous hard disk
access or the ability to call the OS, etc.

A high-priority input-handler that eats all input events starves
Intuition and console.device of input messages.  In my experience that
reduces OS overheads from a max of more than 20% on slow machines when
the mouse moves to a max of less than 1%.

It's hard to imagine a game where all the frames take the same time to
render on all configs within +-1%.  My experience with texture-mapping
engines, for example, is that some frames often take more than twice
as long to render as others.  That's partly due to the fact that walls
are faster to render than floors/ceilings and creatures add an unknown
factor.  Even the angle the player sees the floor can make a factor of
2 difference on some Amigas because the texture may or may not be
accessed in a sequence that utilises the datacache.  Then there are
different configs to consider --- PAL versus NTSC, fast RAM or not,
accelerators can be more than 10 times faster than base machines, etc.

Hence any occasional jerkiness is more likely due to the config or the
game itself instead of the OS.  Techniques such as using the real-time
clock instead of the vblank for simulated time and/or using a
smoothing algorithm to predict the time of the next frame are
effective at smoothing out jerkiness on all configs --- whether the OS
is killed or not.
--
Peter McGavin.   ([e-mail])