Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
InfamousKnight wrote:
What happens: first, I need root just to make any movie.
Did you change the movie path? By default, the movie is stored at the same directory as the executable, which is probably in /usr/bin in your case, which only has root permission.
InfamousKnight wrote:
I done all the configurations you stated, removed all fn keys, and made sure windowed mode was enabled. And set run path(as well as tested it natively) Tried running tgoldeye and it goes for like 2 seconds and crashes before the game loads.
Heres what the terminal says:
Attempt 1: Connected.
10_06 NOT FOUND (tried in tgoldeye tgoldeye)
tgoldeye.svg NOT FOUND (tried in tgoldeye tgoldeye)
Fatal error: Required files are missing, the machine cannot be run.
mame: fccache.c:548: FcCacheFini: Assertion `fcCacheChains[i] == NULL' failed.
Got unknown message!!!
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
I'm even more confused by your message now. First of all, could you check if you have frameskipping and autoframeskip disabled in ppsspp ? Also, could you set "Show FPS Counter" to "Both", so that it will show you the framerate value of the game you are running. Like in libTAS, the first value is the real-time fps value, and the second value is the actual rendering framerate of the game (what I call logical fps). Normally, the first value should match the fps setting in libTAS. And you must set the fps value in libTAS to match the logical fps value of the game, otherwise you will have speed issues.
InfamousKnight wrote:
Well, it looks like a speed problem now. Fps changes constantly while ifps stays at 60.
You are talking about the two fps values in libTAS, right ? The first one is the real-time fps value, it doesn't matter for our issue. Also, make sure by the above comment that your game is indeed running at 60 fps.
InfamousKnight wrote:
While dumping the video, some frames seem to be skipped over, causing desyncs in the end.
You are talking about audio/video desync ?
InfamousKnight wrote:
Speed toggle makes the game run super fast making it a little hard to tas.
I'm confused. You have the tas tools at your disposal (frame advance, slowdown) for that.
InfamousKnight wrote:
I did disable fast forward key with libtas in exchange for speed toggle though.
That's not the same thing ! Keep libTAS in control of the speed.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
Could you describe what issue exactly are you observing ? Constant higher speed than normal ? Or some missed frames ? If libTAS fps setting does not match the game (logical) fps, or if the game has variable fps, then we should see speed problems indeed.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
InfamousKnight wrote:
Does anyone know how much alternate speed 1 increases by? We would have to know how much to slow down the video to proper speed.
Alternate speed 1 is unlimited speed (basically unthrottle), but libTAS is doing the sleeps, so the speed should be correct. However, we would need to investigate how ppsspp handles lag frames (does it display duplicate frames or does it skip rendering) ?
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
Once you have a complete libTAS movie of Citra running a game, playback your movie and add "--movie-record=/path/to/file" to the Citra command-line options. It will record a Citra movie file that you can then playback natively in Citra (on the assumption that movie record/playback is deterministic in Citra). libTAS was only used for the production of the movie but is not involved in the end product.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
If you only need window resizing for encoding, you can add an ffmpeg option to encode at a specific resolution, i.e. "-vf scale=320:240" or "-vf scale=iw*4:ih*4" (iw/ih: input width/height)
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
Dimon12321 wrote:
PCSX2 is a bad choice for learning, as bad as Dolphin is. You ought to pick an easier emulator first: like FCEUX or lsnes. Try to TAS Super Mario Bros, not for submission, but to feel how the TASing process comes over, and to improve your skills, of course.
Getting started with a complex game is a bad sign. I was also inspired by the TASes listed above, I showed this: #4267: Dimon12321's N64 Doom 64 in 41:22.45, and guess what? It was rejected due to my pure skills and bad game knowledge.
Try something simple first, but, nevertheless, it's up to you! Good luck!
I don't necessarily agree with you. Starting with a game that gives you motivation is very important. Doing unoptimized TASes at first is normal, you will improve over time and by sharing them and getting feedback. Also, Super Mario Bros is not a simple game at all.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
Similar to PPSSPP, I was wondering if Citra could run in libTAS. I compiled the latest version (commit d3b1b5f) following the building guide, using "cmake -DENABLE_QT=OFF .." to only build the SDL2 frontend. After compiling and launching the emulator once, I had to edit the config file in "~/.config/citra-emu/sdl2-config.ini", go to the "[Audio]" section and set "output_engine = sdl2" to force using sdl2 audio.
I tested one game only (SteamWorld Dig, maked as Perfect in Citra's compatibility list) using libTAS 1.3.2. Inputs (both buttons and touchpad), savestates, audio, encoding are working. The emulator does not need any more configuration regarding throttling like PPSSPP (frame advance and fastforward work correctly). I could record a movie of the beginning of the game with frame perfect inputs and playback correctly.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
Sorry, I didn't see your post. If the project is named libTAS, wouldn't it be better that the program has the same name ? Also, there's a desktop entry now.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
Version 1.3.2 is out. It includes more game compatibility, some savestate fixes and improvements, more supported Steam games and various bugfixes and improvements. See the full changelog.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
Thanks for the report. FTL uses BASS audio library, which uses unimplemented functions for ALSA. I implemented the necessary functions in commit dca887e, which makes FTL work.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
brunovalads wrote:
I made a proof of concept icon for my idea: a pack of books (= library), just like the WinRAR icon, but with the colours Linux's penguin mascot (black, white and yellow), and "TAS" written on the books. It's just a draft, but something like this could work. My concern is the readability of the letters, since icons get small, so a more minimalistic approach would work better I guess.
Good! I wonder if the books would need an outline, if the background happens to be black ?
feos wrote:
And yeah, everyone views libTAS as the app name I think, even tho the current executional is named differently. Since Linux is case sensitive, the app could be called libTAS, and the .so file - libtas.so.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
Like Hourglass, libTAS tool is actually composed of two files, a program (currently called "linTAS") that is launched by users, and a library (currently called "libTAS.so") that is preloaded with the game to execute custom code. These names come from an old proof-of-concept project that gives some TAS tools to Super Meat Boy.
"libTAS.so" has a name that follows a Unix convention to prefix libraries with "lib" and ending with ".so" for shared libraries, although upper-case letters is rather uncommon. However, "linTAS" is really bad. It looks like a typo, and does not really make sense. I would prefer changing it as early as possible so people don't get used to it. Should we call it "libTAS" or "libtas" ? Wouldn't it be confusing ?
Also, it would be nice to have an icon for the program, so that it shows nicely in the app menu. I'm really bad at this, so feel free to suggest something.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
Sorry, it took me a long time before testing this.
On my computer (Intel Core i3-4330 CPU @ 3.50GHz) using a native Linux (Debian Buster), the time to load levels takes between 100 ms and 250 ms, depending on the level and variability.
I tested on a friend's computer (AMD Ryzen Threadripper 1950X), but inside a Ubuntu 18.04 VM, and it reports the same results (between 100 and 250 ms).
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
Warp wrote:
keylie wrote:
Vsync is turned off using an external program I think.
If that's true, my response is "WTF?" I hope it's not any sort of official speedrun record.
It is considered as a joke category I would say. It is totally unfair as you get significantly better times by having a better computer. Also, you don't need to switch vsync state during the run, just disable it permanently.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
Super Meat Boy is an exemple for how arbitrary framerate and mid-run framerate change can be used. Vsync is turned off using an external program I think. It makes all animations significantly faster. Lowering the framerate is done by holding the Alt key (it doesn't work on Hourglass or libTAS by design), and collisions are only tested at each frame, which makes it possible to go through walls.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
InfamousKnight wrote:
Because I’m having trouble compiling the latest commit, could someone test alternate speed toggle? Instead of unthrottle key?
That’s what they told me here it might just resolve the problem. Also when dumping video, is the frame rate smooth? As in doesn’t have the slow down or speed up? I’m kinda new to this.[/url]
I tested it by setting a hotkey to "Speed toggle" (In System > Controls > Control mapping). Pressing it once switch to "Alternate Speed 1", which is by default set to "Unlimited". Then I press this hotkey at the first frame when executing PPSSPP with libTAS, which makes the game run.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
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.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(2826)
Joined: 3/17/2013
Posts: 391
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.
