I mean with PC games, we have to consider all cases where a game can actually run at uncapped framerate. PC doesn't have hard standard on specs, it can use any kind of compatible component, and games can take advantage of that. PC architecture is open to modifications.
Of course if we emulate a CPU like PCem does, overclocking that CPU by simply hacking its code so that it runs 10 times faster, will probably not be allowed, unless the CPU itself supports this. Similarly, no one cares how fast an emulator can run on the host machine.
But there are several aspects to how fast a PC game can run, and we must consider them all. Be it what we can get with vsync, what we can directly set the game to run at, or what we can get without vsync. Let me know if it's still misleading.
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.
Should the run be allowed to run the game at 10FPS for the sake of being able to use that glitch?
In fact, to emphasize my point, let's not just limit this hypothetical to 10 fps. (After all, a game running at 10 fps is not optimal, but still somewhat watchable.) Let's say that a glitch becomes possible if the game runs at 1 fps. Or 0.1 fps. One frame every 10 seconds.
Needless to say, that would become quite unwatchable. Should it be allowed?
Joined: 8/28/2018
Posts: 75
Location: United States
Warp wrote:
Warp wrote:
Should the run be allowed to run the game at 10FPS for the sake of being able to use that glitch?
In fact, to emphasize my point, let's not just limit this hypothetical to 10 fps. (After all, a game running at 10 fps is not optimal, but still somewhat watchable.) Let's say that a glitch becomes possible if the game runs at 1 fps. Or 0.1 fps. One frame every 10 seconds.
Needless to say, that would become quite unwatchable. Should it be allowed?
If it's the fastest way to do something, it would have a place in the vault.
And in your hypothetical 0.1 FPS situation, it couldn't last for very long or else it wouldn't be the fastest way anymore.
I do not like the idea of limiting the framerates.
feos wrote:
Hard limit for PC games at least for linux seems to be 1,000,000,000fps.
If game theoretically can be played with 1,000,000,000fps on real hardware (supercomputer but still), then i see no reasons why we should forbid recording TAS with this framerate.
So i think existing hard limit for PC games is good enough endpoint. No need to invent arbitrary limitations.
I show you how deep the rabbit hole goes.
Current projects: NES: Tetris "fastest 999999" (improvement, with r57shell)
Genesis: Adventures of Batman & Robin (with Truncated); Pocahontas; Comix Zone (improvement); Mickey Mania (improvement); RoboCop versus The Terminator (improvement); Gargoyles (with feos)
one core guideline for our encodes is to appear, as closely as possible, as though the run was played on the original hardware.
feos wrote:
Unique events may be happening of frames we're dropping, and there can be no way to just dedup them.
Since there are no PC monitors able to display beyond 240 fps, an encode made at 240 fps is technically not dropping anything when compared to "a run played on the original hardware", as it's being perfectly faithful to what the (latest) hardware does display.
It seems to me that this matter should only affect how such runs should be encoded, and not their acceptability. I think that arbitrary fps settings should be treated like any other game setting, and thus be considered in regard of TAS optimality; if there are any potential problems in that regard, then those should be handled separately.
By the way, from what I can see from this site, known refresh rates are these: 30, 60, 70, 75, 76, 85, 100, 120, 144, 160, 165, 166, 180, 200, 240.
To clarify my previous point, I do not mean to present the three ideas as separate items. The intention is that they work in tandem to provide the best coverage I can see for all scenarios. The general idea is to keep things running at the simplest frame rate they can without sacrifice and if it's beyond a practical encoding limit, then encode that with minimum sacrifice.
To summarize: In order to keep things simple, I think 60 or 50 should be chosen where possible. If 60 or 50 is not an appropriate choice for the game, then a higher rate can be chosen (with explanation and justification in the submission text). If it's under 120 (what I'd suggest is the practical encoding limit), it can be any value. If it's above that limit then it should preferably be a multiple of 50 or 60 so that it can be decimated down. The rate it's decimated to will depend on the game and content. Ideally this would be 50 or 60, but if there's a benefit to 100 or 120 then I don't see why it shouldn't be allowed and there may be fringe cases where a trick is only available at 471fps for example, in which a best-case decimation should be applied. The values I provided are just my best thoughts at the moment and can be easily changed.
The problem with relying on current hardware maximums is that unlike console hardware, computer hardware is constantly progressing. If we base limitations on current hardware, as that hardware becomes obsolete so will our limitations, and there's a chance movies will be obsoleted simply from changes in these limitations. Because of that, I don't see a point in capping movies to a specific frame rate, as long as it can be well-justified and caution is exercised. But at what point do encodes become impractical? I'd strongly argue for 120fps and suggest that in cases beyond that the movie file is used for closer examination, or alternatively a higher frame rate encode is given at a basic resolution as an extra encode (much like high resolution encodes for 3D consoles) in specific cases.
I'm not as active as I once was, but I can be reached here if I should be needed.
If it's the fastest way to do something, it would have a place in the vault.
Do you really think that anybody would be happy with a game being speedrun abusing glitches that are only possible if the game is running at 0.1 fps?
Imagine the run itself is an hour long. And it runs at 0.1 fps. Meaning that every still frame is shown for 10 seconds, after which the game jumps 10 seconds ahead in time, and so on. It would effectively be just an hour-long slide show of individual frames.
Let's add more to this hypothetical, and say that running the game at a normal 30 or 60 fps would make the run 1 hour 1 minute long. In other words, running the game at 0.1 fps only saves one minute from an hour-long speedrun.
Would anybody watch such a thing? Would it even make any sense?
Joined: 10/12/2011
Posts: 6337
Location: The land down under.
ThunderAxe31 wrote:
Since there are no PC monitors able to display beyond 240 fps
Hang on, you're missing a few words.
"...for the time being."
After all, 240hz monitors only just hit the market if I'm not mistaken last year. Otherwise your sentence would've said 144hz/fps if that wasn't introduced.
For a future proof case scenario why not just go balls to the walls and go maximum possible at all cases and provide secondary and tertiary as a selectable video source?
We have the resources to do this for PC games.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
Warp wrote:
Doomsday31415 wrote:
If it's the fastest way to do something, it would have a place in the vault.
Do you really think that anybody would be happy with a game being speedrun abusing glitches that are only possible if the game is running at 0.1 fps?
Imagine the run itself is an hour long. And it runs at 0.1 fps. Meaning that every still frame is shown for 10 seconds, after which the game jumps 10 seconds ahead in time, and so on. It would effectively be just an hour-long slide show of individual frames.
Let's add more to this hypothetical, and say that running the game at a normal 30 or 60 fps would make the run 1 hour 1 minute long. In other words, running the game at 0.1 fps only saves one minute from an hour-long speedrun.
Would anybody watch such a thing? Would it even make any sense?
I don't know of any games with glitches that require very low FPS for the whole duration of the run, but I am familiar with a number of games that require very low FPS just for the duration of exploiting a glitch, which is usually only a couple of frames long and doesn't pose much watchability issue.
For a future proof case scenario why not just go balls to the walls and go maximum possible at all cases and provide secondary and tertiary as a selectable video source?
We have the resources to do this for PC games.
Then why not encoding all movies at 32K resolution, since some day 32K monitors will be commercialized?
I think that it would make more sense to stick with the current monitor limitations for encoding, and re-encode a published movie after that monitors with a higher hz hit the market.
Joined: 10/12/2011
Posts: 6337
Location: The land down under.
ThunderAxe31 wrote:
Then why not encoding all movies at 32K resolution, since some day 32K monitors will be commercialized?
Sure, why the hell no-- oh wait, we're currently limited to 16k on YouTube for that.
(even though it displays 8k as a setting cause the feature isn't implemented correctly cough)
But hang on what's this behind your ear. Downloadables!? Gasp
This was the point I was facing toward cause noshitsherlock YouTube only supports 60fps like everyone knows, but what does Downloadables support? Whatever fps and Whatever Res.
The only thing that'll bottleneck is the amount of memory that encoder/publisher has for PC downloadables.
My point's still valid under the case of downloadables (especially when I mentioned selectable video source which you blatantly ignored).
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
Joined: 8/28/2018
Posts: 75
Location: United States
Warp wrote:
Do you really think that anybody would be happy with a game being speedrun abusing glitches that are only possible if the game is running at 0.1 fps?
Imagine the run itself is an hour long. And it runs at 0.1 fps. Meaning that every still frame is shown for 10 seconds, after which the game jumps 10 seconds ahead in time, and so on. It would effectively be just an hour-long slide show of individual frames.
Let's add more to this hypothetical, and say that running the game at a normal 30 or 60 fps would make the run 1 hour 1 minute long. In other words, running the game at 0.1 fps only saves one minute from an hour-long speedrun.
Would anybody watch such a thing? Would it even make any sense?
First off, the vault isn't about entertainment. It's about the fastest time.
More to my point, as YaLTeR said, such a low frame rate wouldn't be done for the entire video; it would last only a handful of frames by nature of the fact every frame costs so much time.
So your hypothetical is a scenario that doesn't exist in reality, and even if it did for some game in the future, that's what the vault is for.
Okay I see the community consensus on framerates when the game runs at regular real-time speed.
Would anyone argue that when gameplay speeds up as a whole as you disable vsync, that must also be allowed? This has already been disallowed for JPC-RR movies as mentioned in the OP.
Also, how does NetHack work in that regard? I remember that it required slowed down encodes, because it's impossible to follow its TAS in real time.
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.
Would anyone argue that when gameplay speeds up as a whole as you disable vsync, that must also be allowed? This was already been disallowed for JPC-RR movies as mentioned in the OP.
That doesn't seem to me to be something that we should allow. If the gameplay as a whole speeds up, then it should in theory be the same TAS just sped up.
[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
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.
Moderator, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
Hi, throwing myself into the fray. First, NetHack is shoving inputs in at up to 700 keys per second and is vastly different than anything else. Likewise, the SMW music 16-bit 32kHz stereo audio payload from total for the SNES completely obliterates any concept of a frame. I'm just going to throw out there that we really need to consider per-poll runs as first-rate citizens so runs like SMB3 17-frame completion are allowed. Yes, per-poll instead of per-frame behaves vastly differently but is *more* true to how consoles really behave, not less. This is a sidetrack but I wanted to highlight it.
Back to NetHack, for all practical purposes I assume that the submission will in fact be in "60 fps" with the result that several screendraws are potentially impossible for the human eye to see but we will make an additional encode allowing for more of the in-between-frames individual input to be observed. Thoughts?
Joined: 8/28/2018
Posts: 75
Location: United States
Memory wrote:
feos wrote:
Would anyone argue that when gameplay speeds up as a whole as you disable vsync, that must also be allowed? This was already been disallowed for JPC-RR movies as mentioned in the OP.
That doesn't seem to me to be something that we should allow. If the gameplay as a whole speeds up, then it should in theory be the same TAS just sped up.
I agree that it's the same TAS but sped up. On the other hand, certain TAS's might be more entertaining/engaging at a higher frame rate.
A blanket ruling on this would hinder the cases where a higher frame rate allowed by the game itself would be better.
More entertaining is a nice pro. What about developer's intention? And about games with slower CPU in mind, whose speed is tied to such a CPU?
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.
Is it really "More entertaining" if it's done at 1 billion FPS and the whole TAS is over in less than a second?
[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
Joined: 8/28/2018
Posts: 75
Location: United States
Memory wrote:
Is it really "More entertaining" if it's done at 1 billion FPS and the whole TAS is over in less than a second?
Of course not. I'm saying that as far as judging is concerned, using a different frame rate here than a previous version should only be considered in terms of entertainment value.
This sounds like changing gameplay speed should be banned from Vault.
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.
This sounds like changing gameplay speed should be banned from Vault.
I'd rather ban it from Moons as well. It's an artificial way of creating "entertainment" and may often result in sound effects going off at the wrong times etc.
[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
Joined: 8/28/2018
Posts: 75
Location: United States
Memory wrote:
feos wrote:
This sounds like changing gameplay speed should be banned from Vault.
I'd rather ban it from Moons as well. It's an artificial way of creating "entertainment" and may often result in sound effects going off at the wrong times etc.
Artificial or not, if it makes it more entertaining, why not allow it?
If people don't like it in certain cases, then it obviously will fail the "more entertaining" threshold.
