This topic is for the purpose of discussing #6104: keylie's Linux TowerFall Ascension "all trials, 1000 fps" in 03:26.75

Is this the first 1000fps TAS on TASVideos?

I'm very glad to start seeing "libTASes" here! And it was a real surprise seeing one of my favourite games of all time being TASed. Great usage of the techniques, and it looks amazing played that fast. Of course a yes, and already my vote for Speedy TAS of 2018"

Technically, this submission breaks the Movie Rules:

No tampering with the files the game is composed of Some systems, such as DOS, exposes the separate parts of the operating system and/or the game to the user. You are not allowed to manipulate these files except as is normally necessary to play the game, such as "installing" it. That means no renaming/copying/deleting/replacing/editing files that affect game-play.

Voted yes anyway. I foresee a clarification of the rules on the horizon.

I can build a verification movie to unlock the four chapters.

From my reading of the submission, I don't see this starting from a save state. This TAS does start from power on as it should. keylie then alters a config file to unlock the areas that should otherwise be locked, and that's what's against the rules. One method to get around the issue would be to create a verification movie unlocking the four chapters and saving, and then start the movie from that save state, but that would require at least some reworking of the TAS to start from the save state instead of power on. I don't know how easy it is to transplant the run from one to the other, but if it's not much effort that would be a good way to go. Otherwise, I think we should discuss how to change the rule on altering game files.

There is a cheat code to unlock everything, that is inputed in the credit screen. I modified the movie to do the cheat code and then complete the trials, so there is no need to modify the savefile: User movie #49970788659983989

Sweet. That gets around the whole issue quite nicely.

I agree with this workaround. Tho, I'd love to see a full "Quest mode" TAS, on Hardcore difficulty. The only problem is unlocking Moonstone, since:

Moonstone can be unlocked in Versus mode. After playing Versus on every starter tower, return to Sacred Ground where on any level where the moon is clearly visible an event will trigger which unlocks Moonstone for play.

I'm not sure if just starting the level is enough to set the flags or you have to finish the battles. Anyways, that's a debate for another time, in a [future] dedicated TowerFall thread.

Since feos is looking for thoughts on how variable FPS games should be handled in the rules, here are my thoughts: * It should not be required to run the game above whatever its default FPS is (or a reasonable default if the game doesn't specify one, such as 60), even if running it faster makes the run faster. * If a TAS is submitted at a certain FPS, and later an improved TAS is submitted at a higher FPS, the second TAS should only be accepted if it has improvements that are not related to simply increasing the FPS and following an identical route. (This is similar to how improvements based entirely on non gameplay frame saves like improved loading times are not considered valid.) * Conversely, if an improved TAS is submitted at a lower FPS, and it only loses time to the FPS being lower, and is otherwise faster due to new tricks/routing, it should be acceptable. (If a trick is only possible at higher FPSes and the trick is now foregone causing a time loss, though, I think -that- should count as being suboptimal and cause a rejection. So the FPS must be at least high enough for all fastest tricks in the run to be possible, and as long as the run optimization/quality increases agnostic to the chosen FPS besides that, the improvement is acceptable.) * The above points all assume the game gets asymptotically faster with higher FPS. If it gets faster with no bound with higher FPS, then allowing TASes to use whatever FPS is obviously absurd - it would be like DOS TASing at arbitrary CPU cycles. In such cases, increasing FPS above the reasonable default (60 or whatever) should be banned. (Side question - does this now mean judges are obliged to research how FPS affects all mechanics and tricks of the game, or should the submitter's research be considered good enough?)

I agree with your first 3 points, Patashu. I think the first point is really important to not force TASers to run at ridiculously high fps. About the last point, I think that it the game becomes faster with no bound when increasing the fps, it can be considered as a serious game glitch. Therefore, I suggest that people may submit a run taking advantage of this, but it will fall into a specific category. There is one example of such case in Super Meat Boy: the first boss is an autoscroller where you have to wait until the boss reaches the end of the screen. Due to poor programming, the boss speed is tied with the framerate, so the higher the framerate is, the faster the boss is going.

* The above points all assume the game gets asymptotically faster with higher FPS. If it gets faster with no bound with higher FPS, then allowing TASes to use whatever FPS is obviously absurd - it would be like DOS TASing at arbitrary CPU cycles.

I was curious as to how this might relate to DOS CPU cycle settings. The CPU cycle limit rule was brought into place to make sure emulator speed settings were not set above what a normal human would be playing at when the game was released. Similarly, I think FPS settings shouldn't be allowed to be set higher than the hardware limitations of the video devices available when the game was released. If it was possible to for a normal human to play at 1,000 FPS (with the appropriate hardware) when the game was released, then this should be allowed. If this is something that can only be done because of the emulator or because better technology came out later, then it should not.

On my Windows 10 host, if I disable vsync in-game, TowerFall runs at 2000 FPS on average, but it doesn't actually run any faster. Since the LTM forces it to run at 1000 FPS, it will effectively dump 1000 frames per second to AVI. Here's a GIF of Twilight Spire II, slowed down to 15 FPS (no way am I embedding that, it's over 10 MB!). As you can see, since libTAS forces it to run at 1000 FPS, it will effectively dump 1000 frames per second to AVI. If you look closely at the timer, you'll notice that every millisecond is present, due to the AVI dump being at 1000 FPS.

* The above points all assume the game gets asymptotically faster with higher FPS. If it gets faster with no bound with higher FPS, then allowing TASes to use whatever FPS is obviously absurd - it would be like DOS TASing at arbitrary CPU cycles.

I was curious as to how this might relate to DOS CPU cycle settings. The CPU cycle limit rule was brought into place to make sure emulator speed settings were not set above what a normal human would be playing at when the game was released. Similarly, I think FPS settings shouldn't be allowed to be set higher than the hardware limitations of the video devices available when the game was released. If it was possible to for a normal human to play at 1,000 FPS (with the appropriate hardware) when the game was released, then this should be allowed. If this is something that can only be done because of the emulator or because better technology came out later, then it should not.

I think another thing to consider here is that most DOS games get arbitrarily (as opposed to asymptotically) fast as you increase their FPS, rather than having things happen at about the same speed, but smoother and responding to input more often. Because nothing interesting happens from a TAS perspective when you speed a DOS game up faster than it would 'reasonably' be played at, this motivates the rule to cap DOS CPU cycle settings at a 'reasonable' value. The argument of using hardware limitations is an interesting one though, and worth considering.

Does the game provide any documented options to adjust framerate? I see framerate=1000 in the config file of the movie. How is this option forwarded to the game?

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.

Okay, and the game itself has fixed speed for all its movements? Or that also changes?

The game physics take into account the time between two screen draws, whatever that is. So everything behave the same for any framerate value. This also applies for non-gameplay sections like the intro or the menus, they take the same time (in seconds) whatever the framerate is. Of course, a higher framerate gives more precision in inputs, so menus may be a little bit faster because of this.

When the rules for DOS movie were created, the main point was that the movie should be using PC specs the game was released for. For example, games that expect slow CPU and are tied to CPU speed, which was common when CPUs were slow, must be TASed with such slow CPU specs. Games that have arbitrarily fast CPU in mind and rely on monitor refresh rate instead, may use as high specs as JPC-RR allows. Does 1000fps setting relate to any real world device this game might be targeting? This number feels fairly arbitrary. If we allow literally anything, the next movie might be forcing 9999999999999999999999999999fps.

Like fsvgm777 said, when you run this game with vsync off, you are getting a framerate of a few thousands, so yes, it is definitively close to what real-world computers are getting. This particular value was chosen because the in-game timer is precise to the thousandth of a second, so any framerate value higher than 1000 would (almost) not affect the obtained in-game time.

Does the game actually render all those 1000fps frames? Maybe the game engine is supposed to support it just fine, and input polling work at that rate, but video rate sounds way overkill.

Yes, the game renders all frames. The in-game timer shows every single thousandth of a second.

Sorry for all these questions, this case is really crazy. libTAS seems to be limited to 100k fps. Where does that number come from?

It is the limit from the GUI integer field (it requires some limit). I just chose an arbitrary high number there, not thinking people will test very high numbers someday :). The theoretical maximum is 1000M fps because time is stored in a struct containing the number of seconds and the number of nanoseconds since 1 Jan 1970. Although, depending on how the game fetched the system time, it can be truncated to a precision of a microsecond (so 1M fps) or even a precision of a milisecond (1k fps) in the case of VVVVVV for exemple.