Games with 30 FPS lock

[Guest]

That would be another way of handling things, but the problem then is how to phrase it. "Frame rate cap" isn't suitable because the tick normally means a feature's state is something good. "Uncapped frame rate" is an option, but determining the existence of an absolute cap beyond the current level can be difficult for the more demanding titles. Additionally, some known caps are very high (a few pages on the wiki list caps in the region of 500-1000 FPS), so a simple pass/fail for the use of a cap would mean such cases would be marked as failures despite the cap being set beyond current frame rate expectations.

Sorry for the late-ish response but you made some really good points here that I've been thinking hard about since you posted ). Also, I think the 60/120+ thing is certainly a step in the right direction.

 

Now, this is going to sound odd considering my stance mentioned earlier, but the first thought I had after seeing the new changes was possibly hiding the 120+ option if it is marked as unknown (or maybe even if 60FPS is marked false as well, though not sure how the on-wiki coding works for that) - somewhat similar to touchscreen support et al..

 

Anyway, one thing that keeps sticking through my mind is that instead of stating it as FPS, rather state it as something like "native 60 Hz support" - though has its own issues and is more of a brainstorming point at this stage :(.

 

Thanks for the great post!

[Guest]

This whole thing seems really pointless to me, it's adding some unnecessary complexity to the video template and the wiki as a whole, the old system was already working pretty well, while also being pretty simple to use, can't we just use the notes field as we always did, in order to state what framerate the game is capped at.

 

I don't really see the point in overthinking this stuff either, the whole input delay thing is also pretty pointless in my mind, I don't care about some of these details, as long as they don't help me solve my problem then I don't care. There's some other reasons to that but these major template changes really need to be thought out a bit better if you really wish to future proof this stuff properly.

[Marioysikax 89]

Ratchet is right that earlier thing was working as it also basically stated 60 FPS, only problem was that there wasn't easy way to collect this information if I'm correct. But now that it's 60 FPS field then other field becomes significally more pointless but still required. So I'm still in favor of turning it into FPS cap field which is hidden by default as majority has 60Hz monitors so they most likely only care about 60 FPS, those wanting unlimited frames or have 144Hz monitor want to know about FPS caps in the game have the other field. This would also make it easier to state e.g. physics, character or camera being locked to certain frame rate as then it has it's own note field. 

 

It's almost like with resolution there's widescreen and 4K. 

[Andytizer 269]

I'm not opposed to listing a framerate cap field, or an input lag field, or even a 144Hz field. However I think these both require further development until we can look to implementing them. In particular,  needs may drastically change in the next 6-12 months as VR become mainstream and high framerate games become very apparent.

 

In the meantime I have spun this 30/60 FPS question off into a new project to crowdsource information on the newly created 60 FPS field, details here: http://community.pcgamingwiki.com/topic/1306-list-of-60-fps-games/

[Mirh 102]

as majority has 60Hz monitors so they most likely only care about 60 FPS

Personally, I have a 60Hz screen and it still matters for me to run unlocked. Don't know why but I can feel something is smoother between 60 and, say, 200.

Could be because sometimes games lock at 60 with vsync crap (input lag/stuttering) or because in what we may call reverse tearing effect, screen as more frames to choose between to "follow my movements".

 

Back to the point of the discussion, I don't see why we should have two rows for a single concept. 60 and 120 FPS seems just two arbitrary chosen thresholds.

We settled to 60Hz because NTSC first and LCD then (or perhaps the latter just adjusted to the former, who knows)

 

Now the highest standard is "3D-grade" monitors but does all of this have really any importance?

I mean: is there a magic limit? If any it shouldn't be tied to technology, that's going to advance until man itself become the bottleneck, I guess

 

And speaking of man, it's not like a game by any other framerate wouldn't play as well.

 

Or better, Shakespeare aside, competitive games like CS or Quake would be basically ruined at 30 FPS.

But actually it's in view of their unlocked nature that they are such competitive. Not the other way around

Then we may say people hate tearing, non-dividers-of-the-refresh-frequency caps, and all.

But this depends upon people sensibility and hardware cases.

 

Example: 30 fps lock: 144Hz screen users are out

60 fps lock: ditto

72 fps lock: nice for 144Hz!... but people with a 120Hz screen would either have different times for frames, or just a 60fps cap

120 fps lock: 144Hz screens users would be angry

144 fps lock (and possibly unlocked to infinite): nice one. Except that every time a new kind of display panel is released we should raise the cap further and further

 

The only occasion as far as I know where high frame rates seem to be really imperative, as I previously said, is with 3D games.

You get sick playing subpar framerates.

 

Establishing what these frame rates are is not something I can do myself.

Though, I know most of the actual tech (which is considered quite satisfactory atm) works between 60 and 90 Hertz per eye.

 

Which I'd say would put the framerate goal games have to achieve somewhere in that 120-180 gray zone that many still can reach.

(I mean, you wouldn't want to set a 500 fps ideal threshold when only 1% of games support that)

 

 

Last but not least, input lag is damn hard to measure.

[Garrett 212]

Pages should all be migrated now. Many thanks to the various editors who have helped rearrange and reword the old notes to suit the new grading.

​

I don't really feel like this is the long term solution to go for. 120+ FPS is not guaranteed for every game that has 120Hz support - there are games that only support multiples of 30 (as a compromise of adding high frame rate support but the engine/game itself not supporting variable frame rate)

​

​To clarify, 120+ FPS grading is the same as high frame rate (it has simply been renamed). Some very old notes (from the 120Hz parameter era) describe refresh rate support instead of actual frame rate.

[Mirh 102]

... I still think we jumped on the bandwagon, just to please fanatics (which even complain about sprites not running at 2 thousands frames per second)

 

Even though I see that 60 and 120 are the two most common refresh rates, they are the same concept. There's no rationale in splitting them imo.

I mean a game can support widescreen, but not 4K, can support multimonitor but not 21:9... can have built-in borderless fullscreen support, but not the usual draggable (potentially resizable) window.

 

These instead are only different points of the same axis.

 

If it was just to make the framerate threshold parsable by mediawiki (and a common text wording wasn't an option), it's not like a |high frame rate value= parameter couldn't be created.

 

Garrett said some games have weird cap arrangements (30 FPS cutscenes, 60 FPS QTEs, uncapped gameplay). But it's not like you haven't to choose only one of them still.

[Mirh 102]

As pointed out by Mairo, we should even take into account there exists game that use vsync to lock framerate

And that nobody forces us to use a true/false value, so we could just insert the exact maximum value and live happy.

[Marioysikax 89]

As pointed out by Mairo, we should even take into account there exists game that use vsync to lock framerate

And that nobody forces us to use a true/false value, so we could just insert the exact maximum value and live happy.

I also stated that they shouldn't exist, as those games are then be automatically broken with over 60Hz displays, most notable examples are Skyrim and Stealth Inc. 2. With Skyrim I can't even advance the first minute of the game because of kilometer long horses and carts rolling hundred times a second - which should be on rails and shouldn't fail. With Stealth Inc. 2 everything runs over double the speed making game much harder. (Sine Mora had this issue, then they introduced cap which broke speedup mechanic of the game and never fixed it nor gave possibility to downgrade to earlier version of the game, so thank you devs!) And with all of the cases I have linked to FPS capping section of FPS article to guide the capping process instead of writing it over and over again. Also been removing changing monitor to 60Hz because of side effects it produces, especially on cheaper end of displays and it's also mentioned in FPS capping.

Then there are tons of similar issues, but other way around, where game enables cap only if vsync gets disabled. Many Unity games do this and they still work just fine with higher frame rates but require vsync to be enabled from the game. (THIS is why I don't like people with 60Hz monitors editing this part when they can't fully test it and only see 60 FPS value with and without vsync)

 

Problem with "exact maximum value" is that if game indeed has vsync forced on, that maximum value for most would be 60 FPS. Of course it can be disabled from GPU control panel, but I'm sure most will not do that to find out will the game run faster than their monitor can show it. If game is new, almost nobody has powerful enough rig to actually get to that maximum value, with some cases it's unlimited, but with some it may be something like 200 or 1000 (yes, I have gotten to few 1000 FPS capped games). At this point I will argue that current system works for now, because it's really easy for anyone to check does the game get to 60 FPS mark and that will be more useful to some that high frame rate value was. After that, it's easy for those with high refresh rate monitors and powerful rigs to see how far does the frame rate get, so 120+FPS field will firstly give guideline to does the game support over 60 FPS values at all and then notes section can be filled with extra info if/when something like frame rate cap field is introduced. 

 

EDIT: I'm still in favor of having input lag and/or frame rate cap field instead, but it would limit significantly who would be able to edit that field and most likely have false information all the time. I remember HFR field being unknown most of the time. It would be neater looking though if 60 FPS field was hidden if 120+FPS was true and 120+FPS would be hidden if 60 FPS were false. 

 

EDIT2: If you meant "vsync to lock framerate" games that have forced vsync? Then it's vsync value, if it's false it means there's no option to toggle vsync and I have always written "Always enabled." if it's forcifully always on. I just remembered that because with vsync, some games do get really irritatingly high input lags when I play with my 60Hz plasma. This is why I was in favor of soebs idea of having input lag field but again, I'm sure there aren't many to be willing to measure such things. BUT with those cases they are simply forcing vsync, not capping the frame rate with vsync. And we do have vsync as part of graphics table. 

Also would like to point out your example of person owning 144Hz monitor, I'm just fine with whatever frame rate game plays, though usually opt to use my plasma with 30 FPS games. It just means I get far less tearing. With Gsync/Freesync even 120 FPS cap is usually fine. 

[Mirh 102]

I also stated that they shouldn't exist, as those games are then be automatically broken with over 60Hz displays, most notable examples are Skyrim and Stealth Inc. 2.

Those are cases where we should just put as value the maximum/only safe framerate and tell people to cap.

 

Then there are tons of similar issues, but other way around, where game enables cap only if vsync gets disabled. Many Unity games do this and they still work just fine with higher frame rates but require vsync to be enabled from the game. (THIS is why I don't like people with 60Hz monitors editing this part when they can't fully test it and only see 60 FPS value with and without vsync)

This seems something worth to be underlined in the editing guide.

 

Of course it can be disabled from GPU control panel

I wouldn't be so sure if I were you.

 

Problem with "exact maximum value" is that [..] if a game is new, almost nobody has powerful enough rig to actually get to that maximum value, with some cases it's unlimited, but with some it may be something like 200 or 1000 (yes, I have gotten to few 1000 FPS capped games). At this point I will argue that current system works for now, because it's really easy for anyone to check does the game get to x FPS mark

Summed up. Imo.

 

EDIT: I'm still in favor of having input lag and/or frame rate cap field instead, but it would limit significantly who would be able to edit that field and most likely have false information all the time. I remember HFR field being unknown most of the time. It would be neater looking though if 60 FPS field was hidden if 120+FPS was true and 120+FPS would be hidden if 60 FPS were false. 

Input lag measurement, albeit interesting seems really hard to achieve.

Personally, I wouldn't introduce it until we haven't a good established method that doesn't require special hardware.

which under way less pompous terms would mean.. your average Android phone. (since I guess this kind of measurement by its intrinsic nature require something external to PC)

 

EDIT2: If you meant "vsync tg 144Hz monitor, I'm just fine with whatever frame rate game plays, though usually opt to use my plasma with 30 FPS games. It just means I get far less tearing. With Gsync/Freesync even 120 FPS cap is usually fine. 

As I said plentiess of times, I never had any annoying tearing problem on my normal TN, and this is no HFR or specially overdriven screen.

The only thing that I guess would extremely annoy me are 45 FPS caps (that is: a frame has 16.6ms and another 33.3ms duration).

But hey, thanks god nobody ever use that value as a cap :p

[Marioysikax 89]

The only thing that I guess would extremely annoy me are 45 FPS caps (that is: a frame has 16.6ms and another 33.3ms duration).

But hey, thanks god nobody ever use that value as a cap :p

Ummmm.... 

*Looks into the direction of God Mode and Spoiler Alert*

 

Summed up. Imo.

 

That's pretty good summ up. Even more summing up is that it's better to have 60 FPS value with "true" or "false" value than frame rate cap with wrong information or nothing at all. 

 

And that summs up that current thing is basically the best, even if it were rushed decision which made it feel like unwanted change. 

[Garrett 212]

EDIT: I'm still in favor of having input lag and/or frame rate cap field instead, but it would limit significantly who would be able to edit that field and most likely have false information all the time. I remember HFR field being unknown most of the time. It would be neater looking though if 60 FPS field was hidden if 120+FPS was true and 120+FPS would be hidden if 60 FPS were false.

​

Displaying both caps is useful for various reasons; among other things it makes the content more accessible through search engines--if only 120+ FPS was shown those pages wouldn't show up as results for 60 FPS queries.

[Mirh 102]

Ummmm.... 

*Looks into the direction of God Mode and Spoiler Alert*

:|

 

That's pretty good summ up. Even more summing up is that it's better to have 60 FPS value with "true" or "false" value than frame rate cap with wrong information or nothing at all. 

Honestly, it's better nothing at all rather than a wrong information.