OSDev.org

John wrote:Based on my understanding, therefore when someone says the video is running at 25 fps, or even 24 fps, that cannot be right...
At 60 hz, the screen refreshes at 0.0167ms.
And 25 fps, the pixels need to switch at every 25 frames. That = 0.04, and this is not a multiple of 0.0167.
Therefore, at somepoint, the video wasnt at 25 fps anymore, but "smear" across?
Am I missing something?

John wrote:So what does it mean when Combuster said it is easy to pump a refresh rate of 500Hz? Is this referring to 500 fps?

And why would vertical refresh rate not stated when we purchase a LED monitor?

I've the impression that vertical refresh rate is no longer a concern with this new LED monitor...

John wrote:So what does it mean when Combuster said it is easy to pump a refresh rate of 500Hz? Is this referring to 500 fps?

tjmonk wrote:For gaming, 60hz is ok, not good enough. Preferred for gaming is 120hz+ For basic desktop 10hz is prolly good enough

tjmonk15 wrote:Just a note. For gaming, 60hz is ok, not good enough. Preferred for gaming is 120hz+. For basic desktop 10hz is prolly good enough, and for youtube/netflix/videos 24-30hz is generally good enough, shy of blu-ray rips.

tjmonk15 wrote:So games aim for the highest possible FPS to give the player the best possible experience. And then they let the graphics card scale it down for whatever monitor the player has.

    while(running) {
        Update_AI();
        Get_user_input();
        Update_objects_and_check_collisions();
        Update_screen();
    }

    while(running) {
        Update_AI();
        Get_user_input();
        Update_objects_and_check_collisions();
        if(screen_hasn't_been_updated_in_the_last_16ms) {
            Update_screen();
        }
    }

    while(running) {
        if(game_state_changed) {
            update_screen();
        }
        wait_until_next_screen_update();
    }

Solar wrote:

tjmonk15 wrote:...

Please don't say "Hz" when you mean "FPS" or "frame rate". Some participants in this thread are already confused enough.

As for your references to Video: PAL is 50 Hz, NTSC is 60 Hz, neither of which is the 24p "movie frame rate" you obviously had in mind, and Blu-ray discs don't exceed a 59-odd frame rate either.

Brendan wrote:Hi,

tjmonk15 wrote:So games aim for the highest possible FPS to give the player the best possible experience. And then they let the graphics card scale it down for whatever monitor the player has.

In general, if a game generates more frames than the monitor can display then the game is a stupid piece of crap that wastes CPU/GPU time for nothing.

Not really. Gamers expect to be able to disable VSync these days. Usually for the reasons you mention below, and others.

Unfortunately, a lot of people who play games aren't very smart and think that "more FPS is better". Even more unfortunately, often these people are actually right, but not because of the FPS. Sadly, a lot of games do something like:

Code: Select all

    while(running) {
        Update_AI();
        Get_user_input();
        Update_objects_and_check_collisions();
        Update_screen();
    }

Labelly Gamers as not very smart can be hazardous to your health lol, though this would be a "safe" place to do it . Also remember that in Game terms, a Frame has several meanings. It can mean what you list above (Graphics, AI, Physics, etc.) all together. And in this case, updating them all as frequently as possible is very, very, very good. (More updates per second allows for better physics simulations, and better AI.)

Because of this, "higher FPS" means that the game is checking user input and responding to it more often; so "higher FPS" actually does help make the game feel more responsive even though the extra frames are a waste of time.

This is a HUGE reason Gamers like/want/demand high FPS. Because like I said, a frame means more than just a screen update.

A better game would do something like this instead:

Code: Select all

    while(running) {
        Update_AI();
        Get_user_input();
        Update_objects_and_check_collisions();
        if(screen_hasn't_been_updated_in_the_last_16ms) {
            Update_screen();
        }
    }

Most new games do this, if and only if, VSync is turned on by the player.

In this case the game would never exceed 60 FPS, but would check user input and respond to it as often as possible (more often than a game running at "higher than 60 FPS" because the time that would've been wasted on pointless screen updates is spent checking for user input, etc).

This would be the best of both worlds until a player has a 75HZ or 120HZ screen. And suddenly this code does more harm than good. Obviously accounting for screen refresh rate would fix this. But with Gamers being used to the way things are, this change would alarm them more than calm them. So this won't happen. (read as a Marketing Decision)

Of course the next step is to use multiple threads/CPUs, where one thread is responsible for doing something like:

Code: Select all

    while(running) {
        if(game_state_changed) {
            update_screen();
        }
        wait_until_next_screen_update();
    }

In Game Programming this generally does more harm than good. There are not a lot of good places to parallelize game logic. Animation relies on game time, Physics rely on animation data (where an arm is in the animation severly impacts whether a bullet hit it or not), rendering relies on both of the above. Don't forget Input changing animations, causing new physics checks to occur, etc. And then add in networking, and realize to get accurate physics (Hit detection and such) you may have to "rewind" several frames, based on ping, to check if the player hit someone when they clicked the fire button, and not now. Everything is too interdependent to make this common place. I'm not saying its impossible, but it is much harder than most people think.

Unfortunately, people who write games aren't smart enough to handle multiple threads (and often aren't even smart enough to add the "if(game_state_changed)" part and will redraw exactly the same graphics repeatedly when nothing has changed at all).

This is because checking if the game state changed would be more expensive than just redrawing the frame. See the list of interactions above to get an idea of the number of checks you would have to make. And don't forget any of those interactions could be altered by a single network packet. And depending on the game, cause the game to go back in time several ms and re calculate EVERYTHING to make up for a bad assumption (because of lag compensation)


Cheers,

Brendan

tjmonk15 wrote:This is because checking if the game state changed would be more expensive than just redrawing the frame. See the list of interactions above to get an idea of the number of checks you would have to make.

turdus wrote:

tjmonk15 wrote:This is because checking if the game state changed would be more expensive than just redrawing the frame. See the list of interactions above to get an idea of the number of checks you would have to make.

LOL. What a bullshit.
Checking game state can be done with an atomic cpu instruction. You set that flag in physics, collusion, AI etc. modules, and clear in redraw. That's all.