(Link to video)
Submission Text Full Submission Page Publication Page
TowerFall Ascension is a multiplayer arena game first released on the Ouya by the name TowerFall in 2013, then later ported to other consoles and PC. The Dark World expansion pack was released two years later. While focusing on multiplayer, this game features a Trials mode where a single player must shoot targets. The present TAS completes all 48 trials of the game, including ones from Dark World expansion.
Below the same video slowed down to 0.25x speed (and still 60 fps). Sorry for the crappy audio.

Game objectives

  • Emulator used: libTAS 1.3.1
  • Completes all 48 trials
  • Aims at fastest in-game time, then fastest real-time
  • Genre: Platform, Fighting

Tricks

(Most of the tricks described here are taken from http://towerfall.wikidot.com/how-to-play )

Dodge-slide

A standard ability, but very important for the following tricks. Pressing the Dodge button while ducking executes a Dodge-slide, which is an horizontal Dodge with a higher velocity than a normal Dodge.

Dodge Canceling

The base of most tricks of the game is the ability to cancel a Dodge at any point by pressing the same or another Dodge button (Hyper Dash), or by jumping if the player is on the ground (jump-cancel). When Dodging, the player starts at a high initial speed, then it decreases rapidly. When a Dodge is canceled by another Dodge, the player keeps the Dodge speed, allowing him to move faster than running speed. A Dodge can be canceled on the first frame after the Dodge for the highest speed. A cancelled dodge also enters the cooldown period earlier, allowing the player to execute another Dodge earlier.

Super Jump

A Super Jump combines a dodge-slide with a jump-cancel. The player must perform a dodge-slide immediately followed by a jump-cancel. The added momentum from the dodge-slide will propel the player forward into the air a great distance.

Hyper Jump

A Hyper Jump is a Super Jump combined with a Hyper Dash. It's executed by performing a dodge-slide, followed immediately by a Dodge cancel, and then a jump. This method gives the highest momentum boost to the player allowing for jumps of huge distances. This is the best way to gain massive speed and launch yourself across the map, since slides are faster than dodges and air friction is lower than ground friction.

Hyper Wing

If a player possesses wings they can perform a technique that sees them fly rapidly upwards into the air. It is performed by jumping with wings when airborne followed immediately by an upwards Hyper Dash.

Air Aiming

During a Hyper Jump, holding the arrow button slightly decreases the air friction, but we loose the player control when aiming in the air.

Framerate choice

Because of the Dodge cancel mechanics, the sooner you cancel the Dodge, the higher speed you gain. As a consequence, a higher framerate gives access to higher speed. The game does not lock the framerate, it depends either on your monitor refresh rate when vsync is on, or your computer processing power when vsync is off. The game engine supports high framerates without any problem. As an example, at a very high framerate (1000 fps), a Hyper Jump gives a velocity 15% higher than at 60 fps. So I decided to record this TAS at a framerate of 1000 fps. This value was chosen for multiple reasons. First, the increased velocity is negligible after around 300 fps. Also, the in-game timer is precise to the millisecond, and behaves correctly regarding frame advancing (advancing one frame always increases the timer by exactly one millisecond). This allows us to complete stages at the best precision displayed by the game.
Edit: I conducted more research on the framerate dependent speed. I took Twilight Spire II stage because you can do an hyper jump across the whole screen. For each framerate value, I performed an hyper jump to the right, using the following inputs: down+right+dash1, right+dash2, right+jump, then I hold these last inputs until getting to the right wall. Before touching the right wall, I released and pressed jump again to buffer a wall jump. Then, I write down the in-game time of first frame of the wall jump animation. The obtained values are:
Framerate (Hz)WJ time
301,533
351,314
401,15
451,022
500,92
550,836
600,766
700,742
800,725
900,711
1000,700
1100,700
1200,691
1400,678
1600,668
1800,666
2000,660
2500,652
3000,646
3500,642
4000,640
4500,637
5000,636
6000,633
7000,630
8000,628
9000,627
10000,627
15000,624
20000,622
30000,621
50000,619
100000,619
The distance traveled is 28 tiles and 6 pixels (so 28.6 tiles because one tile is 10 pixels), so by plotting the character speed in tiles/s over the frame length (in seconds, inverse of the above framerate), we obtain the following graph:

Individual times

StageTime
Sacred Ground I1.151
Sacred Ground II1.542
Sacred Ground III1.082
Twilight Spire I0.770
Twilight Spire II0.812
Twilight Spire III1.392
Backfire I1.307
Backfire II1.144
Backfire III2.106
Flight I1.375
Flight II2.618
Flight III2.002
Mirage I1.180
Mirage II1.726
Mirage III1.678
Thornwood I1.359
Thornwood II1.739
Thornwood III2.036
Frostfang Keep I1.745
Frostfang Keep II1.688
Frostfang Keep III1.602
King's Court I1.761
King's Court II1.701
King's Court III1.210
Sunken City I1.392
Sunken City II2.066
Sunken City III1.387
Moonstone I1.641
Moonstone II1.648
Moonstone III1.365
TowerForge I0.620
TowerForge II1.529
TowerForge III0.762
Ascension I2.305
Ascension II2.227
Ascension III1.562
The Amaranth I1.128
The Amaranth II1.900
The Amaranth III1.448
Dreadwood I1.360
Dreadwood II1.534
Dreadwood III2.201
Darkfang I1.259
Darkfang II1.382
Darkfang III1.637
Cataclysm I1.384
Cataclysm II1.602
Cataclysm III1.777
Total1:13.842
Suggested screenshot: 135663
feos: Submissions with questionable settings need me. Judging...
feos: Replaced with a movie that uses a code to unlock all the trials. Verified sync on 1.3.3.1 version of the game.
feos: Set the branch label that makes it obvious that this movie forces the OS to V-Sync at 1000 frames per second - a value that an original target OS for this game doesn't offer. libTAS intercepts the time functions of the OS and makes the game think that it runs at this framerate, while in reality it's not an option.
feos: We found out "1000 fps" is the most correct spelling.
feos: Finally, the actual judgment.
This movie's goal is completing all the 48 trials the game has, including the locked ones, it unlocks them by using a cheat code, and here's the screen it reaches in the end, showing the results: https://i.imgur.com/JPFchgP.png
I don't think this goal can be considered full completion, because there is also a Quest mode of the main game and of the Dark World DLC. I don't know if it makes sense to beat all Quest levels and all trials in a single movie, this would need some discussion whether we count that as full completion or not.
This movie also happens to abuse the environment in a way not expected by the developers. This is similar to inserting an NTSC-only game into a PAL console and abusing the resulting glitches.
Why is this comparable?
Because the authentic environment the game is developed for is a part of the challenge that the game is. For consoles it just happens to be locked and sealed, and we do not allow to break its integrity. Simply because you can not casually modify your console and then expect legitimacy for your speedrun that abuses these tweaks.
But why do we allow it here?
Because IBM PC officially has open architecture, and one is expected to build their own PC using whatever compatible (or incompatible!) components they can afford.
Yet this obviously doesn't mean that every game can run just fine on any architecture. Quite the opposite: games are usually developed and tested only against a limited set of hardware and software configurations. Those configurations are then announced as minimal, supported, and/or recommended computer specs the game is designed to work on. And on some others (or even some of the intended ones) it may glitch out and become unplayable.
So we allow this to some extent, if it can be proven that a game was designed for some configuration, and it was used. But when one uses configuration not even expected by the developers, we try to limit this approach as not entirely legitimate when it comes to blatantly clear speedrun records. We do not allow abusing unintended environment for Vault. And most importantly: we do not encourage anyone to abuse unintended environment at all. This means a movie doing it may be obsoleted by the one that avoids it if there are gameplay improvements otherwise.
Here's the post speaking of all the aspects of this problem, and here's what our updated Rules say on that matter.
Now, why 1000 fps exactly?
The author provided insight on how this game engine works at higher framerates. After some relatively high framerate value, the trick this movie abuses starts saving less and less time, and its usefulness caps out at around 500 fps.
This movie also aims for in-game time over real time, and milliseconds are the most precise unit of time measurement its timer can work with. So using higher framerate won't affect the in-game timer, because there's no more speedrun benefit for the trick that needs high framerate.
This is still quite arbitrary, but the feedback of this movie is quite positive, so with the about clause on obsoletion, we can allow it here.
Accepting to Moons.
fsvgm777: Processing.

Show more

Hide
1 2 3
Posted: 10/15/2018 7:15 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11267
Location: RU
NES TAS of 2011
Guys please participate: http://tasvideos.org/forum/viewtopic.php?t=20541
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/25/2018 5:13 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11267
Location: RU
NES TAS of 2011
keylie wrote:
The way the framerate setting works is by letting the game think that each screen draw takes exactly 1/fps duration.
Where in the code is it done?
keylie wrote:
The game physics take into account the time between two screen draws, whatever that is.
What OS function does the game use for 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/25/2018 9:42 PM
Quote
keylie
He/Him
Editor, Emulator Coder, Expert player (2827)
Joined: 3/17/2013
Posts: 391
SNES TAS of 2023 PC TASer of 2020 PC TAS of 2020 TASer of 2019 PC TASer of 2019 First edition TAS of 2019 PC TAS of 2019 TASer of 2018 PC TASer of 2018 First edition TAS of 2015 First edition TAS of 2014 Computer TAS of 2013
feos wrote:
keylie wrote:
The way the framerate setting works is by letting the game think that each screen draw takes exactly 1/fps duration.
Where in the code is it done?
keylie wrote:
The game physics take into account the time between two screen draws, whatever that is.
What OS function does the game use for that?
Each function that renders on screen calls function frameBoundary() to trigger the end of the current frame. This function runs all the code at the end of a frame (advancing time, mixing audio, getting inputs, saving the game screen, etc.). This function starts by advancing the system time by calling DeterministicTimer::enterFrameBoundary(). The DeterministicTimer class handles the time that is fed to the game. Each function that queries time is given the state of the DeterministicTimer. All such functions are hooked inside file timewrappers.cpp In the case of TowerFall, it seems the engine queries the time using "clock_gettime()".
Posted: 10/26/2018 4:52 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11267
Location: RU
NES TAS of 2011
I'm confused. Is the game using the same OS functions to see how much time has passed since the last frame, and to get the idea of real world time, so it could keep consistent gameplay speed regardless? Without time calls substitution, it would always have the correct time, just framerate without vsync would be inconsistent, if I'm reading this correctly. And libTAS somehow forces consistent and exact framerate, yet it doesn't actually simulate a CPU speed. It returns false OS time info to the game. I just don't understand how it manages to support real world speed of gameplay regardless.
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: 11/2/2018 5:10 PM
Quote
keylie
He/Him
Editor, Emulator Coder, Expert player (2827)
Joined: 3/17/2013
Posts: 391
SNES TAS of 2023 PC TASer of 2020 PC TAS of 2020 TASer of 2019 PC TASer of 2019 First edition TAS of 2019 PC TAS of 2019 TASer of 2018 PC TASer of 2018 First edition TAS of 2015 First edition TAS of 2014 Computer TAS of 2013
Sorry, I didn't see your post.
feos wrote:
I'm confused. Is the game using the same OS functions to see how much time has passed since the last frame, and to get the idea of real world time, so it could keep consistent gameplay speed regardless?
Well, those are both the same thing, no ? The game queries the time at each frame, to see how much time has passed since the last frame and to feed this delta time into the game engine.
feos wrote:
Without time calls substitution, it would always have the correct time, just framerate without vsync would be inconsistent, if I'm reading this correctly. And libTAS somehow forces consistent and exact framerate, yet it doesn't actually simulate a CPU speed. It returns false OS time info to the game. I just don't understand how it manages to support real world speed of gameplay regardless.
You are using the term "correct time", I would say "actual time". Without time call substitution, it would use the actual time of the machine, which can be pretty much anything with vsync off (and be different for each single game execution). libTAS enforces constant framerate, yes. Again, I would say that it is a "fake" OS time, not "false", because a game could theoretically run at exactly that framerate. I don't understand your last sentence, sorry.
Posted: 11/2/2018 5:22 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11267
Location: RU
NES TAS of 2011
The last sentence is about games that retain gameplay speed regardless of their rendering or input update rate. The action that takes 1 second with vsync 60fps, takes 1 second with no-vsync 4000fps. There could be glitches, but the games are designed to account for hardware speed and whatnot, game engine makes everything happen at the same speed no matter what. So one thing is being aware of real world 1 second and sticking the general speeds of everything to that. And another thing is when we're telling the game 1 millisecond has passed since the last screen update. 2 different entities, 2 timing approaches. My question is how exactly handling both independently works.
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: 11/2/2018 5:58 PM
Quote
keylie
He/Him
Editor, Emulator Coder, Expert player (2827)
Joined: 3/17/2013
Posts: 391
SNES TAS of 2023 PC TASer of 2020 PC TAS of 2020 TASer of 2019 PC TASer of 2019 First edition TAS of 2019 PC TAS of 2019 TASer of 2018 PC TASer of 2018 First edition TAS of 2015 First edition TAS of 2014 Computer TAS of 2013
Oh, I understand now, you are asking how libTAS can run any game at full speed ? When a function is hooked, we still have access to the real function. So libTAS library that is loaded with the game is doing the sleeping at the end of each frame to simulate a full running speed, using a real time OS function.
Posted: 11/2/2018 8:39 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11267
Location: RU
NES TAS of 2011
The thing I'm asking is similar to samplerate. The game is designed to retain the actual speed no matter what, and if you crank up the framerate that libTAS enforces, you just increase the samplerate in terms of frame frequency, without affecting the speed of the action. Like video lag on slow CPU, just reversed. Or imagine shooting a video. You have continuous reality with "infinite samplerate", and your camera films at 60fps by default. That'd be what vsync does in games. The speed of events is the same in both. Drop the filming framerate to 10, same event speed, lower samplerate. This tas is filming reality at 1000fps. Events speeds are unaffected, while precision, samplerate, time resolution increase. The question was, how does libTAS handle both of these entities, event speed and fake OS time? From cwitty's answer, I think it's the same thing as you said: libTAS can be configured which time it would report to the game. Normally, when vsync is on and the hardware runs at, say, 60fps, the game gets the same answer every time: "1/60th of a second has passed since last update". The game then decides how far gameplay was supposed to advance during that time, runs the engine and renders the new frame. As it was said, even with internal vsync off, libTAS still forces consistent framerate whatever we set in the same fashion: it just says "one millisecond has passed", and the game uses that delta to run the engine with this time in mind, and renders a frame that happened sooner than in the first example. Samplerate just increased, consistent delta decreased. Is this correct? Another question, games won't even allow TAS tools if time is not faked? Like, even TASing them with vsync, telling them accurate OS time every time, will we ever be able to TAS them within this workflow?
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: 11/2/2018 9:02 PM
(Edited: 11/2/2018 9:13 PM)
Quote
keylie
He/Him
Editor, Emulator Coder, Expert player (2827)
Joined: 3/17/2013
Posts: 391
SNES TAS of 2023 PC TASer of 2020 PC TAS of 2020 TASer of 2019 PC TASer of 2019 First edition TAS of 2019 PC TAS of 2019 TASer of 2018 PC TASer of 2018 First edition TAS of 2015 First edition TAS of 2014 Computer TAS of 2013
feos wrote:
Is this correct?
Yes, totally. Whenever vsync is on or off, libTAS provides a fake time that is incremented by 1/fps at each frame boundary, so that the delta time between two consecutive frames is constant. Well, to be exact, fake time can also increments in the middle of a frame if the main thread of the game calls a sleep function (by the amount passed to the sleep function). This slept time is subtracted from the time added at the end of the frame, so that the delta time is constant. If the slept time is higher than the length of a frame, then additional (non-draw) frames are triggered to account for the slept time. No sure it belongs to the subject.
feos wrote:
Another question, games won't even allow TAS tools if time is not faked? Like, even TASing them with vsync, telling them accurate OS time every time, will we ever be able to TAS them within this workflow?
There are a few problems with this: - Even with vsync on, you won't have perfectly constant delta times, then those little deviations will probably lead to desyncs - What about if you cannot run the game at full speed ? Or if you pause the game, or fastforward ? - At least, absolute time must be faked because it is used as a seed for most games's PRNG. Replaying a TAS of a game with random elements will desync if the absolute time is different when the game is initializing its PRNG.
Posted: 11/2/2018 9:05 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11267
Location: RU
NES TAS of 2011
What about savestates and frame advance? Are OS time functions involved in these, and if they are, what's their relation to fake and non-fake 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.
Posted: 11/2/2018 9:10 PM
(Edited: 11/2/2018 9:17 PM)
Quote
keylie
He/Him
Editor, Emulator Coder, Expert player (2827)
Joined: 3/17/2013
Posts: 391
SNES TAS of 2023 PC TASer of 2020 PC TAS of 2020 TASer of 2019 PC TASer of 2019 First edition TAS of 2019 PC TAS of 2019 TASer of 2018 PC TASer of 2018 First edition TAS of 2015 First edition TAS of 2014 Computer TAS of 2013
They are not involved, but if you load a previous state, the fake time has to rewind also. This won't be the case if you let the game access to the real time. Edit: I may not have been very clear. Fake time is stored in the game's memory, so it is automatically stored in savestates. When you load a savestate, you will load the fake time from the savestate. Non-fake time is a result of an OS call, so it returns the real value independently of savestates. Edit 2: Yes, they are involved, I meant that there is no specific code to handle fake time regarding savestates, it is part of the game state like everything else.
Posted: 11/2/2018 11:37 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11267
Location: RU
NES TAS of 2011
If a game doesn't have randomness at all, and all it cares about is videoframe precision inputs (or inputpoll precision inputs), will it be possible to properly TAS it with no fake 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.
Posted: 11/3/2018 2:12 AM
Quote
cwitty
Joined: 9/6/2009
Posts: 24
Location: Renton, WA
feos wrote:
If a game doesn't have randomness at all, and all it cares about is videoframe precision inputs (or inputpoll precision inputs), will it be possible to properly TAS it with no fake time?
Well, making a TAS involves single-stepping, and fast-forwarding, and loading savestates. No game that cares about time at all will do reasonable things under those circumstances, so fake time is a necessity for making a TAS of almost any game. I suppose there probably are games where you could somewhat reliably play back a TAS using real time (on a sufficiently powerful computer).
Posted: 11/3/2018 2:24 AM
Quote
Patashu
He/Him
Joined: 10/2/2005
Posts: 4016
cwitty wrote:
I suppose there probably are games where you could somewhat reliably play back a TAS using real time (on a sufficiently powerful computer).
Even then it would be pretty difficult - modern OSes multitask a ton, and you never know when a frame will take slightly too long to compute of resource contentions at the wrong moment. It's not like playing something back on a NES where there's only one thing going on (the game) and no nondeterministic I/O or multithreading. I guess the main 'problem' here is that instead of fully simulating a computer and advancing it by a specific amount of cycles (like JPC-RR), we're residing inside of a computer, fooling another program by swapping out the results of system calls, into thinking that certain amounts of time are passing (and other things). But if something about this 'fake time' concept is suspect, then shouldn't we apply the same suspicion to Hourglass TASes, which IIRC do a similar thing? Obviously the reason why we're talking about it now is to standardize rulings on FPSes usable in Linux TASes, but why was there no similar debate for Windows TASes?
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Posted: 11/3/2018 9:45 AM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11267
Location: RU
NES TAS of 2011
Patashu wrote:
why was there no similar debate for Windows TASes?
I don't think there was a decision not to discuss it back then :D It just happened that either no Windows TAS used translation layer's fake time to simulate crazy framerates, or no one noticed problems for those that did.
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: 11/3/2018 2:34 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11267
Location: RU
NES TAS of 2011
Patashu wrote:
I guess the main 'problem' here is that instead of fully simulating a computer and advancing it by a specific amount of cycles (like JPC-RR), we're residing inside of a computer, fooling another program by swapping out the results of system calls, into thinking that certain amounts of time are passing (and other things).
Now I wonder if consistent 1000fps is achievable on a PCem/QEMU level: can you emulate a certain CPU, install a legitimate OS, and then run the game at consistent 1,000,000 fps? Or 0.30000000000000004 fps? Are such precise framerates even possible on real machines with real OSs?
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: 11/4/2018 12:52 PM
Quote
keylie
He/Him
Editor, Emulator Coder, Expert player (2827)
Joined: 3/17/2013
Posts: 391
SNES TAS of 2023 PC TASer of 2020 PC TAS of 2020 TASer of 2019 PC TASer of 2019 First edition TAS of 2019 PC TAS of 2019 TASer of 2018 PC TASer of 2018 First edition TAS of 2015 First edition TAS of 2014 Computer TAS of 2013
The issue is: during a game, not all frames do require the same amount of processing, so a computer that managed to get a perfectly constant processing power (emulated or real) will not get a constant framerate.
Posted: 11/4/2018 1:39 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11267
Location: RU
NES TAS of 2011
Right. This is why I think consistent arbitrary framerate is unreproducible on a real machine with vanilla OS and no API interception. You're limited to whatever vsync can give you. Can vsync alone force the GPU to render at consistent rate, given it's capable of rendering that fast? For TASing, fake time is often mandatory for sync, but it doesn't seem mandatory to just replay a movie for a game with no RNG at all.
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: 11/4/2018 2:41 PM
Quote
Alyosha
He/Him
Editor, Expert player (3522)
Joined: 11/30/2014
Posts: 2728
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
I can agree that sending fake and precise times to a game that is supposed to be reading real time is not an ideal solution, but it's better then nothing, and we surely already accept worse nonsense then that from emulators. Also yes vote for this TAS, it was a fun fast watch.
Posted: 11/4/2018 9:29 PM
Quote
keylie
He/Him
Editor, Emulator Coder, Expert player (2827)
Joined: 3/17/2013
Posts: 391
SNES TAS of 2023 PC TASer of 2020 PC TAS of 2020 TASer of 2019 PC TASer of 2019 First edition TAS of 2019 PC TAS of 2019 TASer of 2018 PC TASer of 2018 First edition TAS of 2015 First edition TAS of 2014 Computer TAS of 2013
feos wrote:
For TASing, fake time is often mandatory for sync, but it doesn't seem mandatory to just replay a movie for a game with no RNG at all.
This would still require that your computer will be able to keep a constant 60 fps (or whatever value is chosen) when replaying the movie. Even if the game decides to load an entire map in a single frame. Also, delta times between consecutive frames won't be exactly 1/60 seconds, not up to the nanosecond, so you may still get desyncs.
Posted: 11/15/2018 7:18 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11267
Location: RU
NES TAS of 2011
How much time will be lost if FPS is set to 60?
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: 11/15/2018 10:20 PM
Quote
keylie
He/Him
Editor, Emulator Coder, Expert player (2827)
Joined: 3/17/2013
Posts: 391
SNES TAS of 2023 PC TASer of 2020 PC TAS of 2020 TASer of 2019 PC TASer of 2019 First edition TAS of 2019 PC TAS of 2019 TASer of 2018 PC TASer of 2018 First edition TAS of 2015 First edition TAS of 2014 Computer TAS of 2013
The sum of all individual level unassisted WR is 1:37.853 as of now. I would say around half of the time saved is thanks to the high framerate, so about 10 seconds.
Posted: 11/20/2018 7:35 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11267
Location: RU
NES TAS of 2011
the increased velocity is negligible after around 300 fps
Can you elaborate on this? At which point increasing the framerate stops giving any advantage? Also, are there any TAS differences between aiming for real time compared to aiming for in-game time? An example where it matters is Sonic games where in-game time allows fair competition regardless of how much real time the score tally takes. For this game, I expect it not to matter all that much. Progress report: I'm watching the movie suggested for replacement. At 15fps.
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: 11/21/2018 6:36 PM
Quote
keylie
He/Him
Editor, Emulator Coder, Expert player (2827)
Joined: 3/17/2013
Posts: 391
SNES TAS of 2023 PC TASer of 2020 PC TAS of 2020 TASer of 2019 PC TASer of 2019 First edition TAS of 2019 PC TAS of 2019 TASer of 2018 PC TASer of 2018 First edition TAS of 2015 First edition TAS of 2014 Computer TAS of 2013
feos wrote:
the increased velocity is negligible after around 300 fps
Can you elaborate on this? At which point increasing the framerate stops giving any advantage?
The value of 300 fps was a rough estimation when I first started looking into it. I added an analysis on this in the submission text.
feos wrote:
Also, are there any TAS differences between aiming for real time compared to aiming for in-game time? An example where it matters is Sonic games where in-game time allows fair competition regardless of how much real time the score tally takes. For this game, I expect it not to matter all that much.
There is one. When the stage starts, for about 30 frames (at 1000 fps), it is possible to dash or jump, but simply moving right or left has no effect (and does not starts the in-game timer). There are a couple of stages where I needed to start moving left or right. In these cases, I didn't take into account the fact that I lost 30 frames of real time and went for the fastest in-game time.
Posted: 11/21/2018 7:02 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11267
Location: RU
NES TAS of 2011
Thank you. Now 1000fps has some actual details defending it. I'll finish watching the movie, replace it, and render the final decision.
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.
1 2 3