Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Okay so I guess no one minds my suggested rules.
And with no replies about vsync, I think it should also be on by default, unless there are reasons to disable it.
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.
Okay so I guess no one minds my suggested rules.
And with no replies about vsync, I think it should also be on by default, unless there are reasons to disable it.
Personally yes I dont mind these rules. We wouldn’t allow TASing PAL games using NTSC framerates because as far as I know, it wasn’t standard practice to play PAL games like that. Now that we have a system where these settings can be changed easily, it makes sense why we should try to keep playback as close to default settings (while making some acceptions within reason) and not trying to go to insane levels.
[14:15] <feos> WinDOES what DOSn't
12:33:44 PM <Mothrayas> "I got an oof with my game!"
Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet
MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish
[Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person
MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol
Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
I would look into 24FPS as possibly being one of the common framerates - it is (was?) used for movies, though I'm not sure about games.
No, it wasn't.
Monitor refresh rate (i.e. how often your monitor refreshes its screen) is typically 60 Hz (on older monitors), 100+ (on newer monitors), or 50 Hz (on PAL television sets, which are not typically used for PC games).
Game refresh rate, or frame rate (i.e. how often the game is capable of refreshing its screen) depends primarily on CPU speed, and is theoretically unlimited by just buying a faster CPU. Because designers don't (usually) want their game speed to fluctuate wildly with CPU speed, it is common practice to either hard-cap the frame rate (i.e. those menu options we're talking about) or to link it to monitor rate (i.e. by enabling VSync). Because default monitors used to be 60 Hz, the default for framerate has become 60, or sometimes 30 (half that) or 120 (twice that on a newer monitor). This has nothing to do with how many frames movies get, which is a WAY older standard based on 19th century film equipment.
HTH!
^ That doesn't really sound like a convincing argument, so here I go.
Two main points why games didn't run at the movie frame rate of 24 fps were:
- Devices would flicker obviously at 24Hz, distracting from the gameplay or the motion itself
- The utility frequency was getting more and more standardized to 60Hz and 50Hz when display devices were developed, so it additionally became a standard for television and video games as well.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Thank you, Masterjun. I had a feeling there were reasons it wasn't but I wasn't sure, thus I figured I would ask and either find out or it gets considered.
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.
About vsync, if the in-game setting of vsync only sets the underlying GPU vsync setting, then this setting has no effect in the case of libTAS. The tool disables vsync anyway. If the game does something else, then I have no idea what this setting could change.
If we want to be close to real-world environnements, then vsync should be on for common framerates, and off for optional uncommon framerates. I'm not sure it will matter much.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Dropped the vsync clause.
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.
"For other games, if some technique requires uncommon framerate, we allow to use it. Still, do not use arbitrary values, get the technique to work and settle there."
Does this mean that if a glitch is made possible by a certain framerate value (20, for instance), but it is more advantageous at a "more arbitrary" framerate, like 7.5, the less optimal framerate value must be used in the run on the grounds that it's less arbitrary?
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I guess I should have said "get the technique to work optimally".
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.
Not exactly true that "no one minds" them. I have presented my concern. To recapitulate:
If no hard lower limit for framerate is established, meaning that a game could be emulated with as low of a framerate as one wants, this could ostensibly with some games lead to completely unwatchable slideshows.
Someone might discover that in some game, if the framerate is low enough, some kind of glitch becomes possible. For example, suppose that if the framerate is dropped to 1 frame per second, it becomes possible to go through a wall (because the game now makes proportionally larger "jumps" in time, and thus in position, at each frame), skipping part of the level and thus making the run faster.
The problem I see with this is that in most cases it's probably not possible to change the framerate for one particular section of the run only, but that the framerate would need to be kept for the entire run. Imagine, for example, a 1-hour run at 1 frame per second, or even less. It would effectively be a slideshow with very little resemblance to actual gameplay. (Heck, if the framerate is indeed completely uncapped, nothing would stop the game from being emulated eg. at 0.1 fps or less. Imagine every frame being shown for 10 seconds, after which the game just jumps 10 seconds forward to a completely different location. And this for an entire hour.)
Not only would this be essentially unwatchable, I just can't help but to feel that it just goes against the spirit of TASing. It almost feels like some kind of quasi-cheating, where the game is affected by altering an external condition, rather than just playing the game on its own terms, in a normal environment. It's in some ways notionally not completely dissimilar to, for example, running some kind of custom background program that affects the game in some manner.
I would suggest that games ought to be run on the most typical framerate at the time when the game was published. (If we are talking about PC games, perhaps look for the "minimum recommended specs" of the game as some kind of rule of thumb.)
Perhaps more "extreme" uses of FPS manipulation could be limited to Moons and Stars. That way, if the run is as much of a slideshow as you describe, it would have to somehow also meet high entertainment and audience response standards. The question that arises from such a ruling however is where do you draw the line between "okay" and "extreme"? Is 31.25 fps extreme, for example?
Warp, I see your main concern as something that is already taken care of by the existing judging process. If a run is absolutely unwatchable, it won't be published. Or maybe it will? There are already plenty of runs that have slowed-down encodes so that viewers can have a slightly better idea of what's going on. I see no reason why a 60 fps encode couldn't be made of a game that was played slow as molasses.
I can understand your concern that it goes against the spirit of TASing, but I said earlier that I think it's a problem with the game if it can't handle certain settings. And what do we usually do when something is the game's fault? We take advantage of it. I think this concern is just subjective though. There's not going to be a "correct" answer here. But for either case, I think future judgings and audience feedback will slowly veer the site towards its best solution.
There are already plenty of runs that have slowed-down encodes so that viewers can have a slightly better idea of what's going on. I see no reason why a 60 fps encode couldn't be made of a game that was played slow as molasses.
I think there's still a confusion here.
With modern games (and by "modern" I mean games made in the 2000's, and quite a bit earlier in the case of many PC games, probably since 1995 or around that) the framerate doesn't affect playing speed. You will still advance in the game at the same speed. It's just that with a lower framerate the game will "jump forward" at larger steps to compensate. You still get from point A to point B in the same time, regardless of whether the framerate is 120fps or 20fps.
Taking a game that has been played at 1fps and showing the end result at 60fps would mean that everything is happening 60 times faster. Imagine showing something like Doom 60 times faster than normal. It would be unwatchable and incomprehensible.
Showing each frame 60 times (in order to get a "60 fps" video) wouldn't make any difference. You are still staring at every frame for 1 second.
There are already plenty of runs that have slowed-down encodes so that viewers can have a slightly better idea of what's going on. I see no reason why a 60 fps encode couldn't be made of a game that was played slow as molasses.
I think there's still a confusion here.
Wow I'm dumb. That was added as an afterthought when rereading my post, but I probably should have read it one more time.
I still think the concern is covered by the process. An unwatchably slow run will probably have a good chance at rejection. It certainly wouldn't go in moons. It also comes to mind now that a 1fps run is just inherently less impressive from a perspective of precision.
This is really just a personal thing, but if I were going to make a TAS of a modern 3D game on Linux, I would want to TAS it at 120 fps minimum since it's not often you get to make TASes with really smooth framerates like that. As Warp said, the framerate of nearly every modern game, especially on PC, has no impact on the speed the game actually plays at, so that would be a non-issue for most games when it comes to speedrunning or TASing. But I feel like it would be a pretty big boost in entertainment for those with 120+Hz monitors.
Joined: 10/12/2011
Posts: 6439
Location: The land down under.
FitterSpace wrote:
But I feel like it would be a pretty big boost in entertainment for those with 120+Hz monitors.
I feel like I need to stress a point out.
This is only going to be possible if those viewers download the downloadables (hires versions) since YouTube maxes out at 16k60fps.
They would have to go to the site in order to see it playback for those higher refresh rates.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
As Warp said, the framerate of nearly every modern game, especially on PC, has no impact on the speed the game actually plays at, so that would be a non-issue for most games when it comes to speedrunning or TASing.
Yeah, but my concern is that with some games, running it at a ridiculously low framerate might enable some glitches that aren't otherwise. Thus the question becomes whether the framerate should be allowed to be dropped that low for the sake of enabling the glitch.
I understand Warp's concern, in that it reminds me of the alt+tab glitch in Super Meat Boy - by tabbing in and out of the program mid movement, you create arbitrary amounts of lag, and the game's arbitrary frame rate will move you forward by a huge amount and clip you past walls. It doesn't feel like you're really playing the game as intended, but instead exploiting that the arbitrary frame rate has no reasonable limits. But is it different in spirit to lag clipping in DK64? I am not sure if it needs to be specifically ruled out or not - or more to the point, what kinds of objective rules you would instate, if you think this is not desirable.
my concern is that with some games, running it at a ridiculously low framerate might enable some glitches that aren't otherwise
Just like TASing frame-by-frame...
This is fundamentally different. You're quoting Warp, who likes the divine gaming god argument, if I remember correctly. When you're TASing frame-by-frame, you're like some superpowerful being that's literally slowing the passage of time to play the game with extreme precision. To an outside observer, the game behaves as normal. When framerate is lowered on the machine itself, it's not the deity slowing time, it's just the computer. And an outside observer will notice that the game is operating at a different pace.
Yeah, but my concern is that with some games, running it at a ridiculously low framerate might enable some glitches that aren't otherwise. Thus the question becomes whether the framerate should be allowed to be dropped that low for the sake of enabling the glitch.
To me this is not a problem. If the run is not entertaining because of the low framerate, then it will be either rejected or it will go to the Vault.
(...) ridiculously low framerate might enable some glitches that aren't otherwise. (...)
To me this is not a problem. If the run is not entertaining because of the low framerate, then it will be either rejected or it will go to the Vault.
What? I'm pretty sure this is a problem at least for me. Too many pages, didn't read all posts but I guess the general opinion is "no" and "don't like low framerate", therefore it wouldn't be eligible for Vault as well as Moon movies, so TASes would be rejected for this "experience" which bases on the technique of manipulating frame rate, while this is an already known phenomenon and speedruns already uses this in vastly different forms ranging from simple alt-tabbing to seriously slowing down the computer.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Reading the Vault tier description, movies can be ineligible if there's a negative aspect in entertainment., which I find strange for a tier aiming at collecting pure fastest completions for games. But yeah under these rules, movies with low framerate would be ineligible.
