Does 60 FPS really matter?

[Bearcat-Doug | 5,105]

On 10/24/2022 at 10:14 PM, Reed Rothchild said:

Across all of my thousands of games, I couldn't tell you the FPS for any of them.

I couldn't either, but then again my games are so old that I don't think they even go that high.

[OptOut | 8,884]

As an N64 gamer, I can only say:

[Bearcat-Doug | 5,105]

7 minutes ago, OptOut said:

As an N64 gamer, I can only say:

Blast processing fixes this. 

[Sumez | 2,952]

1 hour ago, darkchylde28 said:

If software had been that smart across the entire breadth of video games being produced, we wouldn't have been seeing blank screens, "random" crashes and reboots, etc., when running software on hardware that doesn't support it. 

Well, software needing to understand what hardware it's running on (and then failing to do so) is exactly a reason that you see those things  

1 hour ago, darkchylde28 said:

mine is that the software would have to be aware of what the video hardware was in order to do it.

Nowadays software and hardware can be fairly good at caring less about the exact properties of what they are connected to, but the only way they are able to do that is thanks to additional software and hardware that is then doing that job. But someone is doing the job. Using an old DOS game as an attempt to prove that games don't need to know the hardware they are running on is a little ironic, given just how much hardware configuration often needed to be done in those games in order to get them running properly.

It's an interesting subject, but also really really off-topic to this thread, so I guess if you can't take my word for it, either look up some resources on how video programming is done for video games, or just agree to disagree.  I've tried to explain best I could.

[cj_robot | 542]

18 hours ago, Sumez said:

So why or how is vsync a thing then?  

You could argue a game doesn't talk directly to the hardware, but it talks to a driver that does. Or it talks to an OS that talks to a driver that does. Or it talks to a framework that talks to the OS, etc. But the software absolutely knows if it's targeting a 60hz output or something else. It needs to know.

I think you're overestimating how much those things do for you.  Yes, video cards have video memory for flat textures and render surfaces that will help you buffer your frame for multiple subsequent outputs, but it's really up to the software how to use that.

Just to clarify here, there is no need for the software or hardware to do any "doubling" of frames. Basically, the frame data is located at some specific location in memory, and the hardware (computer, console or whatever) simply sends whatever data is in that spot to the display device. The display device projects that data onto the screen, and it's doing it constantly at 60hz or 75hz or whatever the refresh rate of the device is, whether the frame data is updated or not. All the programmers do is update the frame data. If they update it 30 times a second, then you get 30fps. If they don't ever update the data, then you get a static image, but the software does not have to tell the display device anything to keep displaying the same frame over and over again.

As for Vsync, it has nothing to do with the program outputting frames at a different rate than the monitor. It's about the frame updates not being in sync with the screen refresh. Each screen refresh is extremely fast, but not instantaneous. If you update the frame buffer in memory during the screen refresh, you will get tearing. So, having a vsync option means the program simply asks the hardware to check and make sure the screen refresh is complete before updating the frame buffer. Like you said, the program updating frames at a different rate than the display device could create the appearance of stuttering, but that is not what Vsync fixes.

[darkchylde28 | 1,546]

22 minutes ago, Sumez said:

Well, software needing to understand what hardware it's running on (and then failing to do so) is exactly a reason that you see those things

I'm not saying the ability didn't develop over time, but that instead that it just didn't exist for the bulk of modern video gaming history (going from ~1977 to present, with the start of home PCs).  Hence all the configuration and setup steps that the end user had to do in order for the software to run successfully.  The software had no idea what it was plugged up to and couldn't tell you what was up if/when something went wrong--that was on you to figure out.  So again, the software doubling frames because it's running on a 60fps setup versus a 30fps one would for the majority of gaming history be something that the user would have to tell it to do, because the game was written how the authors programmed it (only for whatever system they were using, in the earliest days) and output what they defaulted it to, not what it thought it should based on hardware detection.

27 minutes ago, Sumez said:

Using an old DOS game as an attempt to prove that games don't need to know the hardware they are running on is a little ironic, given just how much hardware configuration often needed to be done in those games in order to get them running properly.

I find it hilarious that you provided that example, as that sort of proves my exact point.  The game doesn't know what hardware you have, you have to tell it what's there, and how it's configured.  The game itself doesn't need to know anything about the hardware, and it doesn't care--it just outputs what it's told to.  In the cases where there's no configuration option, that's whatever the authors defaulted it to, and in the cases where there's a configuration program, it's whatever the end user tells it to output.  There's zero communication from the program to the hardware to know what's there and what it should be outputting.  Those configuration programs normally had "standard" defaults for the hardware the authors most commonly thought people would have and be using, but you could also change options to suit whatever your personal configuration was.  And if you didn't have the hardware it was expecting, the game wouldn't run right, regardless of how you configured it, and it wouldn't tell you what was up when you got a blank screen, no audio, etc.

33 minutes ago, Sumez said:

t's an interesting subject, but also really really off-topic to this thread, so I guess if you can't take my word for it, either look up some resources on how video programming is done for video games, or just agree to disagree.  I've tried to explain best I could.

I guess it's agree to disagree, as your old school configuration menu sort of proved my point about the older games that make up the bulk of video games up to this point.  If that software knew what hardware there was, it wouldn't need you to configure it, would it? 

[T-Pac | 7,548]

This prompted me to research what framerate modern game-animators work at, and it sounds like a nightmare no matter which way you slice it...

Apparently a lot of game-studio animators work at 30fps, but the game-engines interpolate the motion to 60fps. I'd imagine this leads to a lot of floaty-looking, glitchy results that the artist has no creative control over, which must be frustrating to say the least.

Animators who work at 60fps have the advantage of getting perfect 1:1 visuals of their work in-game, but animating at 60fps must be sooooo labor-intensive. I mean, I usually work at 12fps for TV animation, and it's a struggle just to get 10 seconds of quality animation in a 40 hour work-week sometimes.

TLDR: Video game animators are insane...

-CasualCart

[Sumez | 2,952]

On 10/28/2022 at 4:25 PM, CasualCart said:

Apparently a lot of game-studio animators work at 30fps, but the game-engines interpolate the motion to 60fps.

There's actually a pretty big difference between 30fps animations and 30fps gameplay.
Classic console games like NES, SNES, etc. almost all run at smooth 60fps, but their animations are often much lower than 30.

Edited October 30, 2022 by Sumez

[T-Pac | 7,548]

7 hours ago, Sumez said:

There's actually a pretty big difference between 30fps animations and 30fps gameplay.
Classic console games like NES, SNES, etc. almost all run at smooth 60fps, but their animations are often much lower than 30.

Yeah - that definitely confuses me. So how does it work?

Are the animations just able to update 60 times per second based on input, even if they aren't 60fps? Like - would a 30fps running animation switch to a 30fps jumping animation halfway through a frame if a controller input triggers the jump before that frame's exposure is finished?

-CasualCart

[Sumez | 2,952]

7 hours ago, CasualCart said:

would a 30fps running animation switch to a 30fps jumping animation halfway through a frame if a controller input triggers the jump before that frame's exposure is finished?

Oh yeah, for sure. The animation system doesn't have any such limitations, at least in a common action game. It's all programming.

In more modern (3D) games with a heavier focus on realisim you'll of course more often see animations transitioning into eachother, but that also means those games don't have instantaneous reactions either, though it's usually expected.
A similar example I guess is something like the original Prince of Persia, which has a more "cinematic" style. All your actions in that game are buffered and activated at the right moments according to the main characters currently running state and position.

A fun example I think from a classic 2D game, but with very elaborate (and usually very smooth) animations is Metal Slug, which does the kind of animations that you'd expect adds extra delay to gameplay, but is designed around never inconveniencing the player, such as how pressing down to duck is instantaneous, even though the animation doesn't necessarily reflect that. It makes the game able to both play fair and look good.

Edited October 31, 2022 by Sumez

[T-Pac | 7,548]

4 hours ago, Sumez said:

Oh yeah, for sure. The animation system doesn't have any such limitations, at least in a common action game. It's all programming.

In more modern (3D) games with a heavier focus on realisim you'll of course more often see animations transitioning into eachother, but that also means those games don't have instantaneous reactions either, though it's usually expected.
A similar example I guess is something like the original Prince of Persia, which has a more "cinematic" style. All your actions in that game are buffered and activated at the right moments according to the main characters currently running state and position.

A fun example I think from a classic 2D game, but with very elaborate (and usually very smooth) animations is Metal Slug, which does the kind of animations that you'd expect adds extra delay to gameplay, but is designed around never inconveniencing the player, such as how pressing down to duck is instantaneous, even though the animation doesn't necessarily reflect that. It makes the game able to both play fair and look good.

Wow - that Metal Slug example is genius! So as long as the hitbox responds at 60fps, the game animators can work at whatever framerate they want (within reason) AND have seamless transitions without sacrificing gameplay-responsiveness. 

If it weren't for the effectiveness of intentional delay in some games (like with the Castlevania whip), I would think that all games should be made like this...

-CasualCart

[a3quit4s | 4,099]

On 10/25/2022 at 5:04 PM, RegularGuyGamer said:

Honest question: does it matter what monitor or TV you're using if it hold steady at 30? Like will a low end screen even be able to properly represent 90-120 fps?

Even my wife noticed a huge difference between the Vizio non-OLED I put on our main level and the LG CX OLED I took to the new game room in the basement. Sharpness, colors, and contrast are huge. If you never used a higher end TV before you probably won’t notice a thing, but once you do the picture is so much clearer on OLED. Not sure if it’s the same for monitors, gave up PC gaming almost a decade ago