Game Frame rate and updating questions.

[facultyofmusic]

For some games that I see, no matter how slow to frame rate is, the game processing still goes at a constant rate. In other words, the frame rate doesn't affect the game's speed. Did they achieve this by having a separate thread for screen-updating? If so, should I use the same technique for my own game?

Second thing, what's the average FPS for a small computer game (such as a platform game like N)? The frame rate for movies is 24FPS, but it looks chalky in a game.

Third thing, I don't know if it's because of my computer, but the speed of my game doesn't seem to be constant. My character's moving on a map, and it sometimes goes fast, sometimes slow down. Even if the processing in-between each update take the same time, it still goes sometimes fast and slow. I've heard people saying that java's Thread.sleep() can vary a lot... so how can I know if it's the Thread.sleep's problem or my updating?

[andrew.]

1. You should because then it will be the same speed on fast and slow computers.

2. You should be displaying at least 30 FPS. If you do 24, it may sometimes go under and it will be noticeable.

3. I'm not sure.

[[Gandalf]]

1. Generally the technique that is used is a) a frame rate cap at a certain point as well as b) movement based on time passed since the last frame.

2. This really depends on the game physics. Some games are great at ~30 frames, some need ~90 to feel right.

3. Revert to methods referred to in 1.

[DemonWasp]

1. Gandalf is correct. You should have exactly one thread to keep things simple, and your game's updates (physics, etc) should be based on the time elapsed ("interpolation") since the last frame was drawn. Don't move by speed, move by speed * interpolation.

2. For a platformer, 60FPS is probably quite acceptable. More is almost always better.

3. The amount of work done for each update likely explains most of the variance. Thread.sleep() will vary slightly depending on your CPU scheduler, but will probably not vary tremendously on a modern operating system.

[DtY]

The POV rule (law? Maybe it's not even POV that proves this...) says that a person will see movement if an image changes at at least 10Hz, and 30Hz it will look natural, and anything past 60Hz cannot be differentiated (so yes, 270Hz TVs are meaningless).
Now, like you pointed out movies look good at 24Hz, but games don't. This is because of motion blurring. Watching a movie, it looks sharp, but if you take a still frame, it's blurry, iirc, this is how to eye naturally sees so it looks natural. On the other hand, most games can't (and most computers can't because it's very process intensive) add motion blurring on the fly, so you need to use a faster refresh rate to look as natural (unless you can manage to add motion blurring and keeping it running smoothly).

[edit] Btw, POV here means Persistence of Vision, not Point of View
[edit 2] The reason for number three is that if your computer suddenly does something else (in the background presumably), it has less cycles to deal with your program, so the frame takes longer.

[[Gandalf]]

Heh, that always comes up... Regardless of what the eye can see, the rate at which a game renders frames can have a massive effect on other things critical to game smoothness, like collision detection and physics. Also, refresh rate (commonly Hz) and frames per second (commonly FPS) have little to do with each other.