Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
19:01:26 <Nach> the only reason why games generally even allow turning off vsync is so you can play them on older hardware, which isn't capable of hitting 60 FPS or whatever, or for cases where you have some exotic hardware which doesn't report vsync properly, although in that latter case, there's no telling without vsync will work either
I don't know if we can generalize game dev intents, but this is definitively not the only reason why players disable vsync. Many players disable vsync to get a smoother rendering. Also, on fighting games, players disable vsync to reduce the input lag.
feos wrote:
While consistency sounds like something good, we're not just modifying OS functionality to make the game TASable and then replay the movie without OS hacks. We're hacking OS functions to affect the way the game works. Even though some time functions report proper time, allowing the game to be aware of real world time and work at consistent speed gameplay-wise regardless, other time functions are replaced and report false time altogether.
I'm confused about this part. Yes, we control the time that is given to the game, why do you use the term of hacking ? Also, this is not specific to vsync disabled. Running the game with vsync on does not garantee that the game will run at a constant framerate, it will only enforce a maximum framerate. The game can still have slowdowns. So we also report false time like you say.
Edit: If vsync is on, the game still relies on OS functions, it doesn't use the monitor refresh rate for its physics.
Edit:
18:23:27 <Nach> shoving a PC game onto a PC with specs 20 years later, and running it natively that way is crazy
We mentioned games that run on PCs from the same period at 1000+ fps with vsync off.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
Warp wrote:
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
About libTAS, it supports Dustmod without any problem and can replay inputs made on that tool without desyncs (only tested a few stages but I'm confident).
Regarding the vanilla game, the main issue is a slight change in a trigonometric computation that makes replays from Dustforce/Windows and Dustmod/anyOS desync on Dustforce/Mac and Dustforce/Linux. I don't know the exact change, so I don't know if it could be patched into libTAS to make the replays to sync.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
feos wrote:
If I just manually pause on those frames, how long do I need to wait before unpausing?
About 0.2 seconds I would say, on my computer.
feos wrote:
But how did you get those frame numbers? Maybe the way you got them can be generalized, and there'd be an option to just pause the tool each time a certain event is detected (like creating an uncontrolled thread in this case, if I'm reading it right)?
I got those frames because the game outputs its own log in the console. I could easily see at which exact frame the game is loading another stage.
Yes, I could generalize this for standard situations, for example if the game spawns a loading thread to load the next level, I could detect such thread and wait until it has complete. This would work because the game is using library functions in the process of loadings. I even coded this behavior in libTAS some time ago.
But the problem is: I didn't see any game that follows a pattern that can be visible by libTAS. If we take this game, it spawns the loading thread from the beginning and that thread is given tasks to do in a way that seems invisible to libTAS. I studied another game: Celeste. Because it is coded in C#, we have access to its code. By looking at the level loading procedure, I saw that the loading thread is given tasks by simply changing local variables. This is uncatchable by libTAS in a general matter.
It should be possible to add some code to make those manual pauses for SWD2, but it would work only for that game (basically a hack).
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
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()".
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
Warp wrote:
Getting the low framerate just on the part where the glitching needs to happen, if the game itself does not support capping the framerate to something so low, would require external means of lowering the framerate. If we are talking about an emulated environment (as is most usually the case with TASes), it would require for the runner to manually lower the emulated speed of the emulated hardware for the duration of that glitch.
I doubt that would be acceptable in any way, not under current rules nor probably ever, because it goes against the spirit of TASing (runs shouldn't abuse the emulator itself to make the game glitch. And how would you even theoretically achieve this in the original hardware, without some sort of external software or something?)
Well, you could argue that as opposed to a console (at least old ones), a PC game runs inside an OS that is not entirely dedicated to run the game, so there will be fluctuations of the game framerate depending on what is the OS doing. Could we draw a line between acceptable fluctuations and going from 0.1 fps to 1000 fps ?
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
I just tested ppsspp. I could launch a game, inputs work correctly, but:
* The unthrottle (tab) key must be constantly held. This is because the emulator is dealing with real-time speed in a secondary thread, and this thread is sleeping for 16 ms to get 100% emulation speed. But it is checking that 16 ms has effectively passed, and because it is not done in the main thread, libTAS does not advance time, which results in a softlock. There is no option to force unthrottling, it has to be done with a hotkey.
* Savestates crash, and I don't know why.
* Option "Runtime > Backup savefiles in memory" must be disabled
EDIT: Also, it must be proven that lag frames of the emulated console are translated to frames in libTAS, and I'm not sure it is.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
Thanks for doing all those testings! Error "stack smashing detected" was fixed in commit bc62551. Scummvm and chocolate doom savestates seem to work correctly now.
EDIT: The XIO error was fixed in commit de3a846.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
feos wrote:
Then, what about TAS tricks? What if some trick only works at 4021fps? Also, how is one supposed to check the game on the matter of tricks? Try every idea at literally every framerate? And how are we supposed to judge optimality of a given run?
I don't think this is significantly different from any other TAS trick. You don't check every mid-frame reset on every cycle when judging a lsnes movie. In the speedrun community many games now require setting or changing the fps value to save time (e.g. Bioshock, Bioshock Infinite, The Talos Principle, A Story About My Uncle, Half-Life 1). People are finding those tricks by testing or by chance. So yes, it may be not optimal, and we may have to accept that (except if getting information from game disassembly or open-source games).
About video encode, a 1000 fps video is indeed unwatchable, but videos are not meant to always be played at full-speed. Also, can a video player be told only decode 1 frame every N frames which would provide a full-speed play ?
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
Each level except the first one has two different versions: Crystal and Valkyrie path. On the hub between levels (where you see a pile of treasures), taking the upper path sends you to the Valkyrie path version and the lower one to the Crystal path version.
The conditions to determine which version you can access are:
- You can always access the Crystal path version
- If you have at least one Warrior Spirit collected, you can access the Valkyrie path version
Warrior Spirits can be collected by two means:
- Open three chests in a row while having the full equipment set, the third one will contain a Spirit. In a row means that you cannot loose your equipment in between. This must be done in the same stage.
- If you have at least one Spirit, you gain one by defeating a boss
Warrior Spirits are like lives. When you die, you loose a Warrior Spirit. If you are on a Valkyrie path stage and die without any Spirit left, you are immediately sent back to the Crystal path version of the same stage.
The different Endings are:
- Ending C is when you complete stage 6 of the Crystal Path. You are allowed to skip stages (going to the left at the beginning of a stage sends you to the next stage if you already completed it in a previous playthrough)
- Ending C+ is when you complete all stages in the Crystal Path (except stage 1) without skipping any stage
- Ending B is when you complete stage 6 of the Valkyrie path, without fulfilling all conditions of the Ending A below (you can skip stages)
- Ending A is when you complete all stages in the Valkyrie path (except stage 1). You cannot skip stages. After completing stage 6, a path to a secret stage 7 opens. Completing this secret stage gives you Ending A.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
In addition to setting game path to "[stuff]/game/x86_64/vvvvvv.x86_64", you also need to set in menu "File > Game executable..." the run path to "[stuff]/game/" and library path to "[stuff]/game/x86_64/"
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
I'd like to try to port the current Portal TASes to libTAS to see if it would work, but I'm unsure what would be the best way to do it. Would it be better to:
- Parse SPT .cfg files and convert/export to libTAS input files
- Parse HL2DEMOS .dem files and convert/export to libTAS input files
- Patch SPT, play the demos inside Portal with SPT plugin loaded so that it prints inputs into a file.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2831)
Joined: 3/17/2013
Posts: 391
There are several issues about Dustforce, that you can see in the corresponding topic.
The main one is that all TASes are made on a game mod (called Dustmod) which is based on the physics of the Windows version. Linux (and Mac ?) version has one difference in a trigonometric computation (I couldn't have the exact detail) which makes most of the levels to desync. There is a Linux version of Dustmod which patches this difference, so that TASes sync on Dustmod from all platforms.
The other issue is that screen shaking is random and makes enemies appear early or late depending on screen shake RNG, which I think affect their cycle. This could be fixed by manipulating the RNG to get the correct screen shake.
