I have one more thing to point out.
As I said that we compromise accuracy to determinism if we have to, and we use available bad images if there's no good image in existence, with Hourglass and libTAS we also compromise authenticity of communication between the game and the environment.
This happens because those tools don't emulate the hardware, they intercept the API, they serve as translation layers between the game and the environment. While both the game and the environment may be 100% authentic and untouched, some parts of the environment just have to be faked when fed to the game to allow TAS tools in the first place.
The subject that spawned this discussion, OS time functions, have to be faked by libTAS when the game calls them, if we want TASability. Hourglass and libTAS allow the user to set time delta for a video frame, and the game uses this delta to decide how much the game should advance before the next frame is drawn. And they force this delta to be 100% consistent between frames, resulting in constant arbitrarily high or low framerate, which may not be possible for some games on vanilla OS. So apparently, libTAS and Hourglass force vsync at arbitrary framerates (way beyond what monitors are ever going to support).
It might feel shady to talk about accuracy and authenticity here, but the point is limiting this to cases when it's fundamentally unavoidable, and not extrapolating this to whatever we can possibly want to modify while we're at it. For example, we allow non-original C64 game images that are the only ones available, but we don't allow hacking them further to make the games work faster or something, even though we acknowledge they're already hacked.
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.
Of course there can still be other major problematic situations, even when using "recommended specs" or equivalent. A game from the late 90's could, for example, work properly when using a 3dfx Voodoo card but bug out if using an ATI FireGL card. Should the run be allowed to emulate the latter to abuse some glitches that don't happen with the former?
Actually, the more I think about it, the more of an endless rabbit hole this becomes.
Sometimes graphics card drivers have been buggy, and these bugs have been fixed with newer versions of those drivers. If a particular version of a particular graphics card driver would allow a glitch in some game which wouldn't otherwise happen, should it be allowed?
Which version of the operating system should be allowed? Again, some glitch might happen in one version but not in another.
This is an endless swamp...
To throw something on the table...
Environment a PC game runs within should be legitimate
While IBM PC architecture was open and allowed to use infinite variety of compatible hardware and software components, the games weren't designed to support this infinite variety. Each game usually targets some known specifications and can potentially work on a few deviations of those. Other specifications may be totally incompatible with a given game, and on some variations it can glitch out and not be fully playable.
Means of improving the game's appearance, sound, and alike, without affecting the gameplay, are allowed. This may include in-game options, console commands, launch arguments, in-game codes, environment hardware and software tweaks, etc.
In-game settings and environment parameters that are explicitly supported as modes are allowed. This means there are limited non-arbitrary options the game was designed to work with, for example a few speed variants. Explicit support can be proven by in-game options, official PC spec recommendations, release notes, source code logic and comments, etc. Burden of proof is on the TAS author here. If this information is completely unavailable for a given game, use the environment specs that were common and popular in this game's era.
In-game settings and environment parameters that have arbitrary nature and don't belong to point 1 should be left at default values. Deviations from those are disallowed from Vault. For example, if the game allows to set arbitrary speed factor (even limited to some range), picking arbitrary values can only belong to side branches, not to fastest completion (and%) or full completion (100%).
If arbitrary tweaks don't belong to primary branches, we'd need some branch label they could use, as well as some movie class describing them. While branches can address the specific parameter that was arbitrarily picked, for example "CPU overclock", generalizing all the tweaks under one movie class isn't simple. The thing we want to say is "Abuses unintended environment", "Uses arbitrary environment", but these sound weird.
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.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
After discussion in Discord, I want to write down the case for Half-Life 1 (HL1) variable framerate.
By default HL1 is limited to 100 FPS. It's not vsynced, so depending on the computer performance the FPS can go below, down to 0 (effectively 4 as FPS below 4 is treated as 4 by the game and isn't useful).
The movement is generally faster the higher the FPS, so 100 FPS is optimal for the movement.
The game has tricks which require temporarily lowering the FPS. Examples include fast NPC turning (8 FPS for 1-2 frames), going through thin triggers (20 FPS for 1 frame), edgebug/jumpbug (low FPS for 1 frame depending on player position, sometimes not needed or can be worked around at 100 FPS), fast water entry (4 FPS for 1 frame), small timesaves on doors and scripted sequences (4 or other small FPS for 1 frame). All in all the timesaves here are pretty minor, maybe several seconds over the course of an any% HL1 TAS. However, using all those tricks really does make the run much more technically interesting.
HL1 generally has only 1 category—any%. There's no well-defined 100%, there's no score, etc. RTA people only run any%, any% on a different engine, and any% with some extra console commands allowed. There's also the hazard course, but it's not really a separate category for the purpose of this discussion, more like a separate game with the same set of categories as HL1 itself (any%, any% on a different engine, any% with extra console commands).
An any% TAS of HL1 would take considerable effort to make, and an any% TAS without variable FPS would not look that much different from an any% TAS with variable FPS, so spending 2 times the effort to create both is not really justified. But as I said, any% TAS with variable FPS is more interesting to make and to watch due to technical quality.
For RTA FPS changes to simulate lag are allowed using the fps_max console command. There's been lots of discussion about this within the community, but in the end it is allowed because in theory nothing prevents the computer from lagging at the correct spots, because some people would actively try to simulate lag (launching heavy GPU rendering during cutscenes, why not) and that's just silly to impose on people who want to compete, and because FPS tricks are interesting and fun but not majorly game breaking.
The aforementioned fps_max command can also be used on the Steam version to lift the 100 FPS limit, which is in fact allowed for RTA for this category. For TASing the situation remains similar with 1000 FPS optimal for most of the TAS due to movement, but occasional low FPS frames best for tricks, and also occasional very high FPS frames for other tricks.
The purest HL1 TAS would be using some kind of PCem environment, where the FPS would oscillate a bit just like on a real PC and without the ability to suddenly easily change it. However, the current optimal player movement calculation assumes the ability to control FPS exactly. Moreover, it's not clear at all how to adapt the optimal player movement calculation to the case of oscillating FPS which cannot be exactly controlled. Making a HL1 TAS without this optimal player movement calculation is unrealistic.
Therefore, libTAS is a much more reasonable environment for making a HL1 TAS because the FPS can be fixed at the desired value. However, considering that we're already fixing the FPS to a pre-set value using libTAS, it's easier to justify also allowing to vary this pre-set value over the course of the run to simulate lag and lower the FPS.
To sum up:
- HL1 TASing requires exact control of FPS, whether it's constant throughout the run or variable.
- It has only one meaningful category, which is any%.
- Any% with variable FPS will not look different enough from any% with constant FPS to justify making a separate TAS, or to justify publishing those two TASes in different categories.
- Any% with variable FPS is much more technically interesting.
- RTA rules allow variable FPS.
- libTAS is confirmed to handle HL1's variable FPS tricks fine.
An any% TAS of HL1 would take considerable effort to make, and an any% TAS without variable FPS would not look that much different from an any% TAS with variable FPS, so spending 2 times the effort to create both is not really justified. But as I said, any% TAS with variable FPS is more interesting to make and to watch due to technical quality.
I'd like to back this statement up with an additional note in relation to the beginning of the run. There is a 5-minute unskippable tram ride at the start of the game that is typically ignored in RTA speedruns due to its incredibly long length. The player is able to clip out of the tram by lowering the fps and hit all of the relevant changelevel triggers, but due to certain elements such as doors opening being tied to the tram's position only a few seconds can be shaved over the ride itself, and an extra 40 seconds of waiting for the security guard to walk over to the tram and back again at the end of the ride.
However, there is a major difference in entertainment value between the two. Opportunities for glitch showcases and interesting movement are practically non-existent inside the tram, whereas opportunities are plentiful outside the tram. There is unfortunately little to be showcased on the last of the tram maps, but fortunately the 40 second timesave helps compensate with this issue. While the time difference is still relatively minor over the course of a full TAS, variable fps makes a huge difference to entertainment value over the first 20% of the run, which may be worth noting.
The purest HL1 TAS would be using some kind of PCem environment, where the FPS would oscillate a bit just like on a real PC and without the ability to suddenly easily change it. However, the current optimal player movement calculation assumes the ability to control FPS exactly. Moreover, it's not clear at all how to adapt the optimal player movement calculation to the case of oscillating FPS which cannot be exactly controlled. Making a HL1 TAS without this optimal player movement calculation is unrealistic.
Can't vsync be forced?
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.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
feos wrote:
YaLTeR wrote:
The purest HL1 TAS would be using some kind of PCem environment, where the FPS would oscillate a bit just like on a real PC and without the ability to suddenly easily change it. However, the current optimal player movement calculation assumes the ability to control FPS exactly. Moreover, it's not clear at all how to adapt the optimal player movement calculation to the case of oscillating FPS which cannot be exactly controlled. Making a HL1 TAS without this optimal player movement calculation is unrealistic.
Can't vsync be forced?
Steam HL has a setting to turn on vsync. This removes much of the oscillating, however it doesn't actually fix the frame-time, it's still oscillating a bit. I believe it's still problematic because Steam HL keeps track of the frame-time remainder for the player movement and inserts a lower-FPS frame when it overflows 1 ms. With the kind of oscillating that I was seeing such a frame would occur every ~23 frames, which is too often to be negligible. Furthermore, when looking at a complex scene which causes FPS drops, the frame-time once again behaves haphazardly, hardly usable for movement optimization.
On old WON HL I could not actually find a setting to force vsync.
By default HL1 is limited to 100 FPS. It's not vsynced, so depending on the computer performance the FPS can go below, down to 0 (effectively 4 as FPS below 4 is treated as 4 by the game and isn't useful).
The movement is generally faster the higher the FPS, so 100 FPS is optimal for the movement.
Does this mean the FPS value you use affects your absolute speed that you run at? If so, how does it work exactly?
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.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
feos wrote:
YaLTeR wrote:
By default HL1 is limited to 100 FPS. It's not vsynced, so depending on the computer performance the FPS can go below, down to 0 (effectively 4 as FPS below 4 is treated as 4 by the game and isn't useful).
The movement is generally faster the higher the FPS, so 100 FPS is optimal for the movement.
Does this mean the FPS value you use affects your absolute speed that you run at? If so, how does it work exactly?
Not really, no. It just lets you gain more speed while strafing because it becomes more fine-grained. Imagine approximating a circle with a polygon, it gets closer to the circle shape the more angles there are—it's that kind of change as you increase the FPS, not "computations assume fixed FPS so speed increases" kind of change.
Does the game have any official info on how to control FPS the intended way?
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.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
feos wrote:
Does the game have any official info on how to control FPS the intended way?
I don't know if the current fps_max is mentioned anywhere in official material. The official readme.txt that comes with an old WON version does have a mention of an older variant of that variable (back then fps_max was split into fps_single and fps_lan):
readme.txt wrote:
JUMP KEY NOT ALLOWING YOU TO SWIM UP
If you are having trouble swimming up when you are standing on the ground underwater, try setting fps_lan to a number less than it is currently set to at the console.
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.
It is indeed not a cheat, it can be used in multiplayer as well.
feos wrote:
So if you set those right from console as needed, is it identical to setting it in libTAS on the fly?
It's not identical in the sense that it doesn't fix the FPS, just makes it oscillate under the value that you set. But yes, changing fps_max is how you lower the FPS in RTA runs.
So if you only use in-game console, is it possible to do all the FPS related tricks?
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.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
feos wrote:
So if you only use in-game console, is it possible to do all the FPS related tricks?
Well, Bunnymod XT uses console commands to both fix the FPS (using host_framerate) and send all inputs. However, host_framerate is considered to be legitimate only for TASes and not for RTA runs due to how it works (it fixes the timestep while allowing the game to run as fast as possible).
You're probably asking if it's possible to do FPS tricks by having a constant FPS in libTAS and varying fps_max over the course of the run. The answer is probably? I would need to test how exactly the FPS behaves when doing this. You'd have to bind fps_max n for all values you need in a run to different keys either in a .cfg file loaded by the game or manually using the console before the start of the run. Overall if this approach produces fixed FPS values, I'd say it's manageable and only differs from using variable FPS in libTAS by being considerably more annoying to prepare. I don't think the number of different FPS values will be a limitation, you usually don't need more than a handful.
I guess I'm trying to ask about using console in regular playing environment, as in real-time. libTAS simulates vsync, so I think we don't have to try those with fixed FPS that it forces.
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 you expect the FPS tricks to work with just the console if you run it in PCem?
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 the summary (finally). See if it accurately describes the situation.
Half-Life in-game console is intended for regular use, and it's explicitly and officially recommended, as a workaround for some common issues with the game. Variables that work without enabling cheats (on multiplayer servers) are quite literally not considered cheats by the game and its developers, and framerate cap is one of those variables.
Reducing framerate cap using the console is an official recommendation for one of the known problems. It's never mentioned which value is best, and it doesn't affect absolute gameplay speed, only how often refresh happens. The game doesn't have a setting to force vertical synchronization with the monitor, and default framerate cap doesn't even match what monitors used to be set to.
Fiddling with framerate cap using the in-game console simulates semi-random game lag that may come from the computer hardware, and the game doesn't ever consistently run at fixed framerate anyway.
Running this game in libTAS would force the framerate to some constant value, and if it's not allowed to change, minor speedrunning tricks that depend on framerate fluctuations or console usage won't be available. If we emulate the entire PC with decent accuracy, console usage will be enough for those tricks to work.
Since libTAS is not an emulator, it has to force some environment parameters to guarantee determinism and consistency, which we prefer to accuracy if we have to. It forces fixed framerate in this case. But for games that are meant to provide control over their framerate to the user, forcing just one framerate value for the entire movie is not representative of all the possible gameplay experience.
Therefore, for such games we should allow user to change libTAS framerate on the fly, to replicate what can be done with the in-game console in normal conditions. That allows gameplay available in libTAS to match gameplay available in a reasonably accurate PC emulator.
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.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
feos wrote:
Okay so the summary (finally). See if it accurately describes the situation.
To me it seems like it does accurately describe the situation. I'll ask other members of the speedrunning community to take a look at it too.
One nitpick:
feos wrote:
Variables that work without enabling cheats are quite literally not considered cheats by the game and its developers, and framerate cap is one of those variables.
I'd limit this to "variables that work on multiplayer servers without enabling cheats". There are plenty of cheaty variables that don't require sv_cheats 1 like r_fullbright 1 or the sk_ family that controls health and damage of various entities. None of them can be used on multiplayer servers, there's some other enforcement mechanism for them. fps_max notably can be used on multiplayer servers.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
Would this line of reasoning also allow using unlimited FPS in HL past the 2013 patch?
- On old WON HL you cannot go above 100 FPS even if you set fps_single, it's a hardcoded limit.
- On old Steam HL you can go above 100 FPS by setting fps_max above 100 and setting developer 1 (both work in multiplayer without cheats). However, trying to go above 1000 results in the game staying at 1000 and running faster in realtime. Also due to an absence of the frametime remainder, there's a "FPS slowdown bug" which slows down the player movement if you're using just above 1000 / N FPS. These FPS values are called "stable" because using them or just below makes the slowdown negligible, and setting fps_max to these values achieves exactly that if your PC can keep up. The FPS slowdown bug is present even below 100 FPS but due to its nature at those FPS values it's largely negligible.
- In the 2013 update Valve added the frametime remainder thereby completely fixing the FPS slowdown bug:
changelog wrote:
Improved movement when running at more than 100fps
In the same update Valve added the fps_override variable that now controls the 100 FPS limit instead of developer 1. Naturally, it also works in multiplayer without cheats.
changelog wrote:
Re-enabled a fps cap of 100. You can override this behavior if you want to run faster by setting fps_override to "1" but some mods may not behave properly
This update also allows properly running the game above 1000 FPS, which gives rise to "0 ms" tricks referring to the player movement (floored to a millisecond) being run at 0 ms by using FPS above 1000. Due to the frametime remainder, the easiest way to do those tricks is by using very high FPS frames to avoid overflowing the remainder. E.g. two 2000 FPS frames will result in one 0 ms frame and one 1 ms frame instead of two 0 ms frames, and ideally you want every 0 ms frame in your TAS to be 0 ms. However, you can also insert lower FPS frames with particular frametimes to shift the remainder back where you need it (for instance, if you need one 0 ms frame and one 1 ms frame you could use two 2000 FPS frames which will reset the remainder back and allow you to use 2000 FPS for 0 ms again).
Tricks allowed by 0 ms frames, similarly to low FPS frames, save just a little bit of time over the course of the run and make it more technically interesting. I mentioned it earlier:
YaLTeR wrote:
For TASing the situation remains similar with 1000 FPS optimal for most of the TAS due to movement, but occasional low FPS frames best for tricks, and also occasional very high FPS frames for other tricks.
RTA runs allow unlimited FPS for the Steam version, which usually entails setting fps_override 1;fps_max 999999 to get as close to ≥ 1000 FPS as one's computer allows. 0 ms tricks require TAS precision, so Steam RTA is essentially equivalent to using 1000 FPS with low FPS frames where needed (as opposed to WON RTA, which is using 100 FPS with low FPS frames where needed).
We definitely don't want developer 1 to be used, because it's said to print developer info to the game screen even when the console is hidden, and it's basically a debug mode, therefore explicitly not meant for regular users (CS docs refer to it as something mod developers use).
In that update it sounds like they made fps_override an official thing to play around with, so we allow that by definition. And libTAS's constant FPS that you can change on the fly to some other constant value, replicates what can be done via console, so it's allowed, as long as one only sets vars meant for normal play.
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.
Just wanted to reiterate why all the Half-Life TASes done are not compatible with TASVideos current Movie Rules.
Please note that I'm writing these down from the top of my head, but I believe my information should be correct.
#1 - Enabling the console requires to launch the game with an additional parameter or changing one of the .cfg files that gets executed once the game launches.
Conflicts with the following rules:
http://tasvideos.org/MovieRules.html#NoTamperingWithTheFilesTheGameIsComposedOfhttp://tasvideos.org/MovieRules.html#PcGameEnvironmentMustBeLegitimate
#2 - Manipulating FPS seems to be still not allowed
Conflicts with the following rule:
http://tasvideos.org/MovieRules.html#PcGameEnvironmentMustBeLegitimate
Number 2 also affects TASes like Elasto Mania and any other TAS that requires manipulating the framerate to a specific value using either developer code or an external application.
This means any TAS that uses a platform which has an original built-in OS with the ability to switch between applications or running multiple applications or any physical techniques to manipulate FPS:
- J2ME (KVM), Android, iOS and some other mobile platform
- Mac, Windows, Linux and some other computer platform
- Sixth generation and some other later video game consoles
edit: new stuff in bolded: clarified that I'm talking about a selection of, not all platforms of.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
