Post by Memory

Posted: 10/15/2018 7:15 PM

Post subject: Limit on framerate for PC games

Quote

feos

Site Admin, Skilled player (1254)

Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg

Last year there was a thread about DOS games, where it was decided: - If gameplay is tied to real world time and doesn't speed up or slow down depending on CPU speed, CPU speed for such a game can be maximized to reduce lag. - If gameplay is tied to CPU speed, and the game slows down or speeds up along with CPU config, CPU speed must be set to whatever was common when the game was released. This only talks about JPC-RR and its capabilities. There is one more aspect that can depend on the CPU speed - framerate of the video that comes from the emulator. DOS games don't use framerates too much above 70, and JPC-RR doesn't output arbitrary framerates, so for DOS games, even if they send frames to the VGACard at 1000fps, it's not a problem when it comes to displaying the video and dumping it to the file. For PC games, this may be problematic. When VSync is used, games use to render frames at common framerates the monitor and the video card are configured to. The most common framerate is probably 60fps. There are monitors that support up to 240fps. Video cards support theoretically unlimited framerates, it just depends on complexity of a given game and what processing it involves. For high resolutions, high settings, and modern games, framerates GPUs can output don't go above 300. Now, with VSync disabled, a game may run at uncapped speed. If this just removes lag, we can handle this the same way we handle DOS games. If gameplay speeds up, we must limit framerate to whatever it's meant to be played at. But what if the game has fixed real world speed for everything, but happens to render frames at uncapped framerate? A 1000fps video is unwatchable due to heavy lag, and due to countless dropped frames as far as the monitor is concerned. Let alone human eye and what it can percept. Hard limit for PC games at least for linux seems to be 1,000,000,000fps. So if you're running a game on a quantum computer, my first question is WTF are you smoking, and the second question, who needs that framerate in games? Due to inability to watch encodes at insanely high framerates, we have to limit maximum allowed framerate we let the games run at. Because we can't simply drop frames from encodes on a regular basis only to make the watchable. Unique events may be happening of frames we're dropping, and there can be no way to just dedup them. Any artificial limit seems to be arbitrary. VSync for any game that can render frames at uncapped framerate sounds like a good limit to me. But even then, the computer can be configured to run at framerates above 60. Where should we stop? 240fps? 60fps? Something else? And why there?

Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.

Posted: 10/15/2018 7:40 PM

Quote

Doomsday31415

He/Him

Active player (298)

Joined: 8/28/2018
Posts: 75
Location: United States

Is the file size of a (for example) 1,000,000 fps bk2 file significant enough that it's a concern? I would think that the encoding can be done at whatever frame rate is viewable, dropping non-viewable frames as needed. If you really want to see what it looks like on each frame, there's still the bk2 file.

Posted: 10/15/2018 8:04 PM

Quote

feos

Site Admin, Skilled player (1254)

Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg

Having ridiculous framecounts in movies is another topic, and it's not the reason we would want to limit the framerate for. We've always aimed to provide encodes that accurately depict the contents of the movie. http://tasvideos.org/EncoderGuidelines.html#Introduction http://tasvideos.org/EncoderGuidelines.html#VideoCapture We can't just ignore these principles. Moreover, even if high fps is allowed, where should it stop? 1000fps feels arbitrary. Actually, any framerate that's not commonly used is arbitrary here. Then, what about TAS tricks? What if some trick only works at 4021fps? Also, how is one supposed to check the game on the matter of tricks? Try every idea at literally every framerate? And how are we supposed to judge optimality of a given run? Sorry that I forgot to mention all this in the OP, but this all defeats the questionable benefits of allowing unlimited framerates.

Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.

Posted: 10/15/2018 8:55 PM

Quote

keylie

He/Him

Editor, Emulator Coder, Expert player (2841)

Joined: 3/17/2013
Posts: 392

feos wrote:

Then, what about TAS tricks? What if some trick only works at 4021fps? Also, how is one supposed to check the game on the matter of tricks? Try every idea at literally every framerate? And how are we supposed to judge optimality of a given run?

I don't think this is significantly different from any other TAS trick. You don't check every mid-frame reset on every cycle when judging a lsnes movie. In the speedrun community many games now require setting or changing the fps value to save time (e.g. Bioshock, Bioshock Infinite, The Talos Principle, A Story About My Uncle, Half-Life 1). People are finding those tricks by testing or by chance. So yes, it may be not optimal, and we may have to accept that (except if getting information from game disassembly or open-source games). About video encode, a 1000 fps video is indeed unwatchable, but videos are not meant to always be played at full-speed. Also, can a video player be told only decode 1 frame every N frames which would provide a full-speed play ?

Posted: 10/15/2018 9:01 PM

Quote

FitterSpace

Active player (465)

Joined: 3/30/2012
Posts: 405

I definitely understand the need for a framerate limit in TASes for computer games. But you're right in that whatever framerate you choose is going to be arbitrary. If there is going to be a limit, I suggest having it at 360 or something higher as long as it divides into 60 evenly. That way, encodes will look as good as possible for the majority of people that will be watching with a 60Hz display since you can decimate the framerate evenly. For example, a TAS that plays at 360fps can be made into a 60fps video by dividing the framerate exactly by 6. I chose the number 360 because it's the next number higher than 333 that's divisible by 60 (many first-person shooters are optimal at 333fps). However, there will always be exceptions, and I think that a TAS should be able to use an arbitrarily high framerate if there is a good reason to. A good compromise with something like that would be providing 120fps encodes and continue allowing people to download the input file and play it back if they want to watch at the highest possible framerate.

Finished projects: 007: Nightfire 007: Nightfire "All Tokens" Goldeneye: 007 (Wii) Feng Shen Bang (Famicom)

Posted: 10/15/2018 9:05 PM

Quote

feos

Site Admin, Skilled player (1254)

Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg

If we can't display the video of a movie accurately, it breaks the encoding principles I linked above. And if we allow 1000fps or 360fps, we inherently allow 1 billion fps, because where to draw the line and why? Any number that isn't commonly used nor intended is arbitrary. And we can't design rules that have loose ends like that.

Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.

Posted: 10/15/2018 9:18 PM

Quote

InputEvelution

She/Her

Editor, Reviewer, Player (36)

Joined: 3/27/2018
Posts: 194
Location: Australia

I would like to take this opportunity to point in particular to Half-Life 1, and the way that framerate has an impact on TASing. Tons of fundamental speedrunning tech rely on the framerate, and not necessarily in a consistent way, either. Control over framerate (or more accurately, frametime) is highly valued in that game and others that use the engine. The ability to have a high framerate is valued equally to the ability to have a low framerate. To limit TASers of that game to a value like 60 would be to tell them not to make an optimal TASes at all. Here's an example of a TAS (made with an injector tool called Bunnymod XT) that takes heavy advantage of the framerate: https://youtu.be/WsuYogNgDSo

Posted: 10/15/2018 9:29 PM

Quote

Doomsday31415

He/Him

Active player (298)

Joined: 8/28/2018
Posts: 75
Location: United States

feos wrote:

If we can't display the video of a movie accurately, it breaks the encoding principles I linked above.

But if the viewers can't view a video above 120 FPS anyway, what's the point of encoding beyond that?

Posted: 10/15/2018 9:29 PM

Quote

FitterSpace

Active player (465)

Joined: 3/30/2012
Posts: 405

If a new thing comes around that can't work with the way the rules are now, then the rules need to be updated. That, or an exception needs to be made for PC games. I think it would be best to allow a TAS to use whatever framerate the author wants (including changes in the framerate as TheProJamer pointed out). But there is obviously no way to reasonably encode a video at something like 10,000 fps. So either there needs to be a limit on the framerate the TAS itself uses or a limit to the framerate they can be encoded at. Neither solution is ideal, but I would prefer giving authors more control over the framerate they choose since every game is different.

Finished projects: 007: Nightfire 007: Nightfire "All Tokens" Goldeneye: 007 (Wii) Feng Shen Bang (Famicom)

Posted: 10/15/2018 9:43 PM

Quote

feos

Site Admin, Skilled player (1254)

Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg

TheProJamer wrote:

I would like to take this opportunity to point in particular to Half-Life 1, and the way that framerate has an impact on TASing. Tons of fundamental speedrunning tech rely on the framerate, and not necessarily in a consistent way, either. Control over framerate (or more accurately, frametime) is highly valued in that game and others that use the engine. The ability to have a high framerate is valued equally to the ability to have a low framerate. To limit TASers of that game to a value like 60 would be to tell them not to make an optimal TASes at all. Here's an example of a TAS (made with an injector tool called Bunnymod XT) that takes heavy advantage of the framerate: https://youtu.be/WsuYogNgDSo

Can the user control framerate during regular play within the original unmodified game, and outside of any internal replay functionality?

Doomsday31415 wrote:

But if the viewers can't view a video above 120 FPS anyway, what's the point of encoding beyond that?

Have you read what I linked?

Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.

Posted: 10/15/2018 9:51 PM

Quote

Memory

She/Her

Site Admin, Skilled player (1556)

Joined: 3/20/2014
Posts: 1765
Location: Dumpster

On the subject of Half-Life, only the Steam version has uncapped framerate that is controlled by the user. This version lacks several tricks from the WON version however, and is not typically used for speedruns. The WON version has user controlled framerate capped at 100FPS I believe. Anything that uses WON version tricks with higher FPS than 100 is modded to be able to do such. This is forbidden by the RTA community's rules. However, I do not like the idea of limiting the framerates for arbitrary reasons, especially relating to encoding. If an encode fails to be able to capture at a high framerate, that is a failure on the part of encoding technology, not on the author. For all I know a game may be set by the developers to run AT MINIMUM a framerate which our encoders cannot properly handle. Any rule limiting FPS would feel arbitrary to me as such.

[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours

[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero

Posted: 10/15/2018 9:55 PM

Quote

feos

Site Admin, Skilled player (1254)

Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg

Encoding at this framerate is fine I think (though I admit I haven't even googled 1 billion fps). The problem is that it's impossible to watch.

Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.

Posted: 10/15/2018 9:56 PM

Quote

Memory

She/Her

Site Admin, Skilled player (1556)

Joined: 3/20/2014
Posts: 1765
Location: Dumpster

feos wrote:

Encoding at this framerate is fine I think (though I admit I haven't even googled 1 billion fps). The problem is that it's impossible to watch.

Then it would be a failure of the video replay technology. Alas I don't think we should tailor our rules to the limitations of current software as these rules may long outlast such limitations.

[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours

[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero

Posted: 10/15/2018 9:58 PM

Quote

Doomsday31415

He/Him

Active player (298)

Joined: 8/28/2018
Posts: 75
Location: United States

feos wrote:

Doomsday31415 wrote:
But if the viewers can't view a video above 120 FPS anyway, what's the point of encoding beyond that?
Have you read what I linked?

I have, and I agree with FitterSpace and Memory that TAS's shouldn't be limited by encoding framerate.

Posted: 10/15/2018 10:00 PM

Quote

YaLTeR

He/Him

Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia

Hey, my two cents from my Half-Life 1 TASing experience. The framerates matter a lot here, and there's valid use for really high framerates, too. The TAS linked by TheProJamer heavily utilizes 1 000 FPS, but has a number of 10 000 000 000 FPS frames. This particular number was chosen somewhat arbitrarily, it simply needs to be high enough. The reason is as follows. In Half-Life, player movement frametime is floored to the nearest millisecond, so 1 000 FPS is 1 msec and anything above is 0 msec. 0 msec results in no player movement happening, while discrete actions such as crouching and uncrouching still taking place, allowing for crouching and uncrouching on ground without any speed loss due to ground friction. However, the remainder of the frametime flooring is stored and accumulated. If a whole millisecond is accumulated in the remainder, it is added to the frametime. This way, two 2 000 FPS frames (1 000 / 2 000 = 0.5 msec) would result in one 0 msec frame (0.5 msec stored in remainder) and one 1 msec frame (0 msec + 1 msec accumulated in the remainder). When using 10 000 FPS, a whole millisecond accumulates over 10 frames, and so on. Since we don't want any extra 1 msec frames, we want to set the FPS reasonably high, so that over the course of the TAS we don't accumulate more than a millisecond of remainder by using the 0 msec frames. Now the way the video capturing tools work is really simple: you set the desired output framerate (for example, 144 FPS) and the capturing drops or duplicates actual in-game frames to match that framerate. This has proven to work really well for Half-Life and can deal with all of those weird billion FPS cases. As an additional benefit, it's possible to capture a high enough FPS TAS (like 1 000 FPS) with different output FPS values, like 120 FPS for 120 Hz screens and further conversion to 60 FPS for YouTube, and 144 FPS for 144 Hz screens (which is exactly what I've done for that TAS).

Pushing Half-Life to its limits.

Posted: 10/16/2018 1:45 AM

Quote

TheCoreyBurton

He/Him

Joined: 10/14/2013
Posts: 335
Location: Australia

I think perhaps several different ideas are needed to be combined here. My thoughts are as follows: 60fps should be encouraged where possible, as it's the de facto standard. 50fps could also be commonly acceptable for similar reasons. For arbitrary frame rates (such as 71, 93 or 111), a cap at 120fps is placed. This covers current DOS publications, allows for games with odd native rates, and also allows for high-frame rate publications without putting unnecessary strain on the encoders or viewers (the latter due to file size or playback requirements). For excessive rates (such as 360 or 1000), they could be acceptable as long as they're a multiple of the two standard rates mentioned above: 50 or 60. In these cases, the runs could be decimated down to those frame rates (or maybe even 100 or 120, depending on if the higher frame rates are allowed) when encoding, but frame-specific tricks could still be performed (and watched with the input file). Regarding the fact we'd lose a large portion of video data doing this, it's theoretically no different to running a game at an unlimited frame rate on a 60hz screen. You might be getting 1000fps generated a second, but you're only seeing 60 of them and so the viewing experience won't necessarily be different to the on the game actually provides. Edit: In the last scenario, it should probably also be possible to play back the movie at the higher rate (for example 600fps) whilst dumping at the decimated rate (for example 60fps) in order for this suggestion to be practical. Whilst the decimation can be done in AVISynth, at higher resolutions 1000fps will not only take an incredible amount of time, but will also use an absolutely gargantuan amount of HDD space. For reference, a few 4K Dolphin dumps I've done lately have hit the 2tb mark and they're only 60fps.

I'm not as active as I once was, but I can be reached here if I should be needed.

Posted: 10/16/2018 5:22 AM

Quote

YaLTeR

He/Him

Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia

I don't think restricting framerates to multiples of 50 and 60 is a good idea. Apart from arbitrary nature, the goal (dropping an exact number of frames to achieve a common framerate) is a little flawed. For example, take Half-Life with its default 100 FPS. In TASes you usually move by strafing and strafing usually results in the camera facing slightly to the left on one frame and slightly to the right on every other frame. By dropping half of the frames to make the encode 50 FPS, you'll end up dropping exactly those frames where the camera is looking one of the ways, and the resulting footage will look like the camera isn't moving at all (misrepresenting the TAS). The best way I found here is to dump at 100 FPS for downloadables (so people with high Hz screens can watch an extremely smooth video) and at 60 FPS for YouTube (which preserves the camera movement exactly because it's not an even division). The same issue comes up with any sort of 1 frame on 1 frame off flickering. Besides, at sufficiently high game FPS any judder resulting from converting to a lower FPS which isn't an exact divisor won't be noticeable at all.

Pushing Half-Life to its limits.

Posted: 10/16/2018 5:27 AM

Post subject: Re: Limit on framerate for PC games

Quote

r57shell

Player (98)

Joined: 12/12/2013
Posts: 379
Location: Russia

feos wrote:

Video cards support theoretically unlimited framerates, it just depends on complexity of a given game and what processing it involves. For high resolutions, high settings, and modern games, framerates GPUs can output don't go above 300.

It's limit for swapping buffers. But real hardware always has connectors for display. And this hardware outputs are limited.

feos wrote:

If we can't display the video of a movie accurately, it breaks the encoding principles I linked above.

Sometimes you should update your principles by adding some exceptions for example. My opinion: 1) Don't restrict TAS-ers, because TAS is art, and artist should not be restricted :) 2) Don't require encoders to be supermans who should make video closest to real playback of movie. Let them just make encode as best as they think, and leave decision of what encode setting and methods to use to they own choice.

Posted: 10/16/2018 6:38 AM

Quote

YaLTeR

He/Him

Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia

Another point against arbitrary FPS limits, once again from the game of weird FPS effects, Half-Life: for general movement you want to use "stable" FPS values that are equal to 1 000 / n FPS for integer n, however for a certain movement glitch you want to use a lowest FPS value above a stable FPS value, so that would be (something along; it depends on floating point rounding) 500.00001 FPS or 250.00001 FPS.

Pushing Half-Life to its limits.

Posted: 10/16/2018 2:05 PM

Quote

Warp

Banned User

Joined: 3/10/2004
Posts: 7698
Location: Finland

What happens when some glitch or skip is tied to a particular (or maximum/minimum) framerate? For example, assume that some kind of glitch is only possible when the game runs at 10FPS or less. Should the run be allowed to run the game at 10FPS for the sake of being able to use that glitch? Should the run be allowed to change the framerate mid-run in order to get the glitch? This is not a purely theoretical question. I am aware of at least one modern game out there where certain glitches are possible only when running the game at a low framerate (namely, The Talos Principle.) There are probably more. (Personally, I really detest the abuse of framerate changes in order to trigger such glitches in speedruns. Especially since it involves the runner going to the game's graphical settings menu and changing the framerate cap there, doing the glitch, and then going back and changing it back to what it was before. But that's a pet-peeve of mine, and a different topic.)

Posted: 10/16/2018 2:20 PM

Quote

Doomsday31415

He/Him

Active player (298)

Joined: 8/28/2018
Posts: 75
Location: United States

Warp wrote:

What happens when some glitch or skip is tied to a particular (or maximum/minimum) framerate? For example, assume that some kind of glitch is only possible when the game runs at 10FPS or less. Should the run be allowed to run the game at 10FPS for the sake of being able to use that glitch? Should the run be allowed to change the framerate mid-run in order to get the glitch?

I'd say this is no different than changing the battle speed in a Final Fantasy game or the text speed in a Pokemon game. It's an option the game provides, so it should be usable.

Posted: 10/16/2018 2:23 PM

Quote

Warp

Banned User

Joined: 3/10/2004
Posts: 7698
Location: Finland

Doomsday31415 wrote:

I'd say this is no different than changing the battle speed in a Final Fantasy game or the text speed in a Pokemon game. It's an option the game provides, so it should be usable.

I think the original post is talking about the speed of emulation, not some setting inside the game itself. This is what I was referring to. Should the TAS be allowed to set the emulation speed to 10FPS for the sake of allowing the glitch to happen?

Posted: 10/16/2018 3:01 PM

Quote

feos

Site Admin, Skilled player (1254)

Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg

It's actually about both.

keylie wrote:

No, the game does not offer an option to adjust framerate, there is just the vsync option. It is uncommon for games to offer a framerate setting, generally they run as fast as possible when vsync is off, or at the monitor framerate when vsync is on. The way the framerate setting works is by letting the game think that each screen draw takes exactly 1/fps duration. It corresponds to a different real-time situation if the vsync option is on or off, but the result is the same. If vsync is on, it's the same as saying that you plugged a monitor that has a refresh rate of the framerate setting. If vsync is off, it's the same as saying that your computer has a certain processing power so that it runs the game exactly at this framerate.

Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.

Posted: 10/16/2018 3:08 PM

Quote

Memory

She/Her

Site Admin, Skilled player (1556)

Joined: 3/20/2014
Posts: 1765
Location: Dumpster

feos wrote:

It's actually about both.

It's fairly misleading to call that emulation speed however if it more relates to the power of the computer running it or in this case the power the software is told is running it (even if it's not actually on a computer of that power). EDIT: Why this is important to note is that this isn't like an emulator played on turbo or emulating a NES that has been overclocked past its normal limits. A PC may theoretically have the power to support any framerate and be INTENDED to be able to run at that framerate. All that is happening in the case feos mentioned is that libTAS tells the game that it is a supercomputer of sorts.

[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours

[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero

Forum General Limit on framerate for PC games

Forum

General

Limit on framerate for PC games