bontz-team
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bontz-team] animation and drop-frames


From: chuck
Subject: Re: [Bontz-team] animation and drop-frames
Date: Thu, 09 Oct 2003 14:30:08 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030924 Thunderbird/0.3

this is a known issue, and i wasn't planing on fixing it until i fix the sprite classes. the sprites move x pixels every time you go through the loop, there is absolutely no timing on it unlike the characters animation tracks which is timed.

Owen Swerkstrom wrote:

I think I mentioned this before, but since there's
been some activity in the codebase again recently, and
since I was probably not very clear before, I'll say
it again:

The animation system does a perfect job of making sure
the game doesn't go too fast on a blazing fast
machine, but it doesn't help move things along on one
that's too slow.  If I remember right, it checks to
see how much time has gone by since the last draw and
if it's been long enough, moves the character so much
and gets ready for another.  On my old slow dual 450,
with only the few characters in the demo on-screen,
it's notably slower than on my 2 ghz box at work.

If, for instance, we're supposed to only do a
move/update every n milliseconds, the fast box gets
'round to that point in the loop every n-m
milliseconds, where m<n.  On an old pathetic machine
though, it only gets to that point in the loop every
n+o milliseconds, where o might be very slight, or it
might be several times n!  Point is, we have to
compare "how long it's been since the last draw" to
"how long between desired draws" and check that it's
not gone overboard.  If it turns out it's been five
times n since the last update, we need to move our
character not just d pixels but 5*d pixels in whatever
direction he's running.  Also, the remainder (and this
is even when the extra wait is not double "n" but not
equal to it or less either) should be tacked on to the
"last draw time", so that if a computer's somewhere in
between and doesn't need to drop 4 frames for every 1,
but has to drop say 1 frame every 10 or something,
that will still happen and the movement will be the
same exact speed (just choppier) on a slow machine as
a fast one.

I hope this makes sense.  Now that it's fresh in my
head, unless one of you wants to show me up and beat
me to it, I'll try to write a patch tonight.  Not sure
how smart it is for us to keep patching and
bastardizing that which is already hacky and
quick-put-some-pretty-pictures-on-the-screen-y, but
the concepts will travel over to a cleaner codebase
once we have it sorted out how it all is to be organized.

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


_______________________________________________
Bontz-team mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/bontz-team






reply via email to

[Prev in Thread] Current Thread [Next in Thread]