-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Framerate Difficulty Problem #2
Comments
Hi John,
What you're seeing is the result of deltaTime moving the bird the same
distance over time but over fewer frames, so you do have the end result of
sometimes moving through obstacles that you normally would not.
To fix this, what you would want to do is check to see whether deltaTime
(dt) between frames is greater than 1/60th of a second; if not, you can
just multiply things as normal and perform the collision detection once,
but if it is, you want to perform the collision for however many times 1/60
divides into dt (i.e., if 2/60th of a second elapse, you want to check
collision twice). We don't get into the mechanics of making this work
smoothly in this course just because it gets a little bit more complicated
implementing a more robust system and students often have enough of a time
understanding dt and how to use it.
But long story short, you'll have to figure out how many frames have
elapsed if greater than 1 and do the collision that many times instead of
just the once :)
Best,
Colton
…On Thu, Aug 9, 2018 at 3:27 PM John Lardinois ***@***.***> wrote:
Hi, I'm not sure what's going on, but it seems that when I play my
completed game on crappy systems, it's significantly easier because it
seems like the bird doesn't jump as high or fall as fast. I'm assuming this
is an issue with framerate and deltatime.
I noticed this while testing on a Dell Inspiron laptop. ( parents'
computer )
I got scores higher than 30 several times, and only died because I made
the bird fall to end the test. It really could have gone on indefinitely.
The narrowed "jump / fall range" makes it very easy to slip through small
pipe gaps. Is it a known phenomenon for framerate to affect a game this
way, or is this just all a fluke?
Is there a way to compensate for low framerates in the gravity code?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADjTkeWuhsqstilEFlxNl07dfi9CAZ7Cks5uPI00gaJpZM4V2Rjc>
.
|
@coltonoscopy what would be the recommendation when it comes to 60+ FPS? It's quite unplayable at 144 :) |
@snekbaev Limit dt with some min_dt: https://github.com/games50/fifty-bird/pull/15/files |
@sharifmarat can't recall the details now, but I think the suggested approach wasn't good enough. I remember reading some article about fixing the frame rate issues using different methods and pros and cons of each. One of the better ones was to use the accumulator approach. I think I've implemented some variation of that |
A few years late to the party, but I didn't see this mentioned anywhere, so FWIW I'll explain why you experienced this issue and share a fix for it. Hopefully it will help future students: **tl;dr: ** Pull Request #21 will fix this issue. We'll start by discussing basic physics (probably mandatory knowledge for game developers anyway): now, when we calculate the bird's speed this is done correctly, we take the gravity and multiply it by the elapsed time, dt, giving us the speed: Line 45 in fb37701
And indeed, when looking at the units alone, (pixels / second ^ 2) * seconds = pixels / second and those are indeed the units of speed as expected.
The mess starts when we try and add this speed to the bird's y position: Line 52 in fb37701
Notice how we take the bird's current y position and add the speed to it without multiplying it by the time elapsed, dt. This makes no sense in physics. You can't simply add two measurements of different units! To demonstrate how this affects users who run on a frame rate which is not 60 fps, let's consider two users, user A and user B.
Running the above code prints:
so over the same timeframe, user A saw the bird move 26 pixels, and user B saw it moving 50 pixels, almost twice as much! How can we fix this?
However, this will cause the bird to move much slower, and we will need to set new values. |
Hi, I'm not sure what's going on, but it seems that when I play my completed game on crappy systems, it's significantly easier because it seems like the bird doesn't jump as high or fall as fast. I'm assuming this is an issue with framerate and deltatime.
I noticed this while testing on a Dell Inspiron laptop. ( parents' computer )
I got scores higher than 30 several times, and only died because I made the bird fall to end the test. It really could have gone on indefinitely.
The narrowed "jump / fall range" makes it very easy to slip through small pipe gaps. Is it a known phenomenon for framerate to affect a game this way, or is this just all a fluke?
Is there a way to compensate for low framerates in the gravity code?
The text was updated successfully, but these errors were encountered: