I was taking a break from working on my App and started playing the game Bio Shock. Just for a frame rate test, I set Bio Shock on a x16 samples with a 1280x768 resolution. I knew the game would suffer in frames, but I wanted to see how smooth the game looked when losing frames.
You see… I’ve always had this theory that, if values in a Panda3D App were x by the globalClock.getDt(), the entire Application would probably play faster at low speeds. I never tested this theory and just figured it was impossible to do what other commercial games do…look smooth at low frame rate.
I saw Bio Shock do something Apps in Panda3D do. When the frame rate hit a certain low…Bio Shock flattened out at 30 fps. I knew Panda3D also did the same thing and after seeing that, I just had to test my “Global Clock” Theory.
My “Global Clock” Theory turned out correct! I ran my App with a forced frame rate of 30 fps and everything still looked smooth. “Darn” glad I discovered how to get the low fps/smooth animation duo; this will ensure that the App will look fairly smooth if the frame rate suffered on slower machines. E.g. 2.4 ghz (single core)
My question is, does every value have to be multiplied x the globalClock.getDt()? What I’ve done was multiple every value that adds or subtracts from.
E.g.
x+1.0
Changed to:
x+5.0*globalClock.getDt()
I even change comparison values.
if x+2.0 > self.Zval:
To:
if x+20*globalClock.getDt() > self.Zval:
I wonder if it’s necessary to change all values that add or subtract like that, in order to get smooth Animation at low frame rates? If there’s a better way, please collaborate.
Yes, it’s important to multiply by globalClock.getDt().
You have to multiply everything by frame time, otherwise if your character walks (say 10 panda units a second, running at 30fps) then when you switch to a faster computer running at 60fps, your character would walk 20 panda units a second.
Unless of course, you multiply it by the delta time, using globalClock.getDt(), then it’s the speed times the frame time which removes the dependency on the framerate.
I guess the rotation of the screen can’t be helped though…I guess that much was expected. Lower frame rate means more motion blurr for things in the distance, but only during rotation for me. If a character was going in a straight line and the camera followed, there wouldn’t be any motion blurr at 30 fps; but when that character starts going side ways, making the view spin, I get the motion blurr.
I saw that same issue with a Resident Evil game I played…I think it was Res4 (PC). The game had a 30 fps limit and there was some motion blurr when the view started to twirl. So I guess all in all…that part is natural.
I thought I was leaving something off of the globalClock.getDt() and that was causing the Blurr, but I don’t think so; looks like it’s just the 30 fps doing that.
Anyway, I wish the Manual mentioned little things like this.
Well the manual is a wiki, so perhaps one of us could add a “General video game programming” explaining general knowledge like what fps actually is, and how to multiply things by the globalClock.getDt() to make sure that thing’s are framerate independant
The reason is because things are multiplied by the delta, it comes out so that frames jump quite a bit (instead of the game going slower), which is of course natural because that’s (normally) the max that your hardware can pump out. You never want to go above your moniter’s refresh rate though, because it’d be a waste of resources. That’s why panda has video-sync turned on by default and limit’s your framerate to that of your moniter’s refresh rate.
So all in all, yes, multiplying by globalClock.getDt() is the correct way to stop things from being framerate dependant. And yes, lower framerates will “jump” more and/or cause a “motion blur” effect.
It’s not a magic “multiply by globalClock.getDt() and it’s smooth”. You have to know the theory behind it.
In the case of movement, it’s basic physics. We all know that:
Δs = v * Δt
So the distance travelled is the product of the velocity and the elapsed time.
In the case of movement of an entity in a task, we want to know how much to move the entity. We know more-or-less how fast the entity should go. So applying this formula:
p.setY(p, 1000 * globalClock.getDt())
Because the time is in seconds, and “s” is in Panda units, the velocity is in Panda units per second (relative to the coordinate space of the node, in this case it is p).
So in this case, if you put that in a task, the player will constantly move forward at a speed of 1000 panda units per second.
If you don’t multiply by globalClock.getDt(), though, this is what you get:
p.setY(p, 10)
This is incorrect, because you’re assuming that the elapsed time is a constant value. Now, if your game ran at a constant 60 FPS, no big deal. But you’ll want your movement to be independent of the framerate, so you need to multiply by the elapsed time.
So, it doesn’t make sense to go and multiply everything by the elapsed time. You shouldn’t multiply anything by it except when you’re converting speed or velocity into distance.
It’s kinda hard to understand your question or theory. Maybe try to convert your thoughts into a problem and then re-discuss.
Also note that there are a lot of different frame-based speed issues in a game. Monitor refresh rate; world refresh rate; physics update rate; animation update rate; sound sample rate. Of course a 10 FPS animation of a sprite in an old 2.5D shooter game suddenly looks smoother when the game is running too fast on modern hardware. Just like movies from the early 20th century look smoother played in today’s projector’s, yet the characters move too fast. Just like you actually had to speed up or speed down or up-sample or down-sample sound in a video game when you increase or reduce speed of your game.
There should be no game that “probably play faster at low speeds”. Maybe the FPS of sprite-based animation look better in certain constellations of animation-FPS vs. monitor-FPS. Maybe a slow strategy game does suffer less from low FPS then a shooter does. But did you mean these aspects?
You already said yourself that games use motion blur to compensate for fast movements. That’s what Hollywood movies do, too. That’s one of the reasons why small camcorder clips look so different from real movies. Blur helps to compensate for low FPS for example when the camera moves with a train or helicopter and it helps DVD compression.
My question was answered. Should globalClock.getDt() be multiplied by everything? Straight forward question. The answer is no. I even came across some issues multiplying some values by globalClock.getDt() and now have learned to identify the values that need it vs those that do not.