Steam probably won't work, because it says 'Also, Steam games won't work because Steam messes up with our code injection, so you must check if a drm-free version of the game exists.'.
I read that in wiki, but missed it in mind. Well, at least libTAS provides savestates for those games that doesn't have them if you want to complete a difficult event in a game while a regular walkthrough though I don't think it will work.
TASing is like making a film: only the best takes are shown in the final movie.
Steam games support is under work, by implementing a dummy libsteam_api.so implementation. It is half-finished, but some games are already supported. Some games uses other ways to connect to Steam, like launching steam runtime (1001 spikes is one example), and I don't know yet how to handle them.
About 3D games, there is nothing that specifically prevent 3D games from working, but it is more about the engine. You should be able to get Unity 3D games to work (I tested Gone Home some time ago). The Unreal game I tested (Antichamber) crashes at the beginning.
Joined: 9/12/2014
Posts: 543
Location: Waterford, MI
[Edit] I got it to work by enabling permissions to run as executable. And no, it doesn’t work because of the graphical user interface that pops up before the game begins.
I'm having trouble running unity on ubuntu 18.04.
I looked up a page on how to do it https://blogs.unity3d.com/2015/08/26/unity-comes-to-linux-experimental-build-now-available/ and it says its missing some shared libraries when I try to open the editor.. I found a game on itch.io called "grand theft audio 3" and wanted to test it. I would imagine it would work. I also downloaded latest build on there. No installation issue, just whenever I run it, it gives me shared libraries missing.
Yeah, the game comes inside a zip archive, which does not store file permissions, you need to add exec permission to the binary.
Some Unity games show a startup window, which breaks libTAS for now. I've looked if there is a way to disable it using a commandline option but it seems it's not possible (there is a commandline option to force that window to show...)
Joined: 9/12/2014
Posts: 543
Location: Waterford, MI
Interesting. I’ve saw on an old todo list that you were going to resolve multithreaded games with a correspondence table? That’s clever. That todo list should help with motivation though. Better yet a schedule for it.
Now that this is apparently accepted to the site, I wonder would it be allowed to obsolete some movies done on Windows with the Linux ports (if exists)?
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
jlun2 wrote:
Now that this is apparently accepted to the site, I wonder would it be allowed to obsolete some movies done on Windows with the Linux ports (if exists)?
As always, only if the ports are deliberately and vastly similar.
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.
Some Unity games show a startup window, which breaks libTAS for now. I've looked if there is a way to disable it using a commandline option but it seems it's not possible (there is a commandline option to force that window to show...)
I figured out how to disable the startup window, for at least a couple of Unity games. Find any files named ScreenSelector.so and remove (or rename) them. (More specifically, remove Plugins/x86/ScreenSelector.so if you're on 32-bit, or Plugins/x86_64/ScreenSelector.so if you're on 64-bit.)
As far as I can tell this has no effect on gameplay. Of course, I can't predict whether the judges would allow this for an actual submission; the rules say "No tampering with the files the game is composed of", but that's later qualified with "no ... deleting ... files that affect game-play", so it might be allowed?
Joined: 9/12/2014
Posts: 543
Location: Waterford, MI
I found that in the exact same area with grand theft audio iii, but now the game insist on preloading the library. Which is what was said in the command-line.
Is there any way to bypass the ldpreload on that ONE library? Because libtas uses ldpreload to inject code otherwise.
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
cwitty wrote:
I figured out how to disable the startup window, for at least a couple of Unity games. Find any files named ScreenSelector.so and remove (or rename) them. (More specifically, remove Plugins/x86/ScreenSelector.so if you're on 32-bit, or Plugins/x86_64/ScreenSelector.so if you're on 64-bit.)
As far as I can tell this has no effect on gameplay. Of course, I can't predict whether the judges would allow this for an actual submission; the rules say "No tampering with the files the game is composed of", but that's later qualified with "no ... deleting ... files that affect game-play", so it might be allowed?
This approach would be iffy. It's always better to properly support such things if possible, rather than hack them away. But if it's really unavoidable even after reasonable efforts, we may allow a simple innocent tweak under some conditions.
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.
I found that in the exact same area with grand theft audio iii, but now the game insist on preloading the library. Which is what was said in the command-line.
Is there any way to bypass the ldpreload on that ONE library? Because libtas uses ldpreload to inject code otherwise.
By just deleting ScreenSelector.so, I could launch grand theft audio iii correctly with libTAS. Mouse inputs don't work for some reason.
Joined: 9/12/2014
Posts: 543
Location: Waterford, MI
It might just be my virtual machines graphics card, something flashes and goes right away in a frame when opening without. I’ll do some updates and see. Thanks for testing though!
Note: Windows version works f
Joined: 9/12/2014
Posts: 543
Location: Waterford, MI
I'm still having problems running 3d games on my virtual machine with ubuntu 18.04
My computer supports vulkan and is a i5 core processor, but I don't understand why the virtual machine won't run 3d games like grand theft audio 3
Exact steps to reproduce, install fresh ubuntu 18.04, run updates, run guest additions, restart machine, turn off machine, enable 3d acceleration under display, start up machine, get gta3 from itch.io, run it under windowed mode to see if it works, and it doesn't..
Is there anything I'm doing wrong?
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.
EDIT: There was a bug in the released version. I've updated compiled files with the fix.
Version 1.3.3 is out. The new features are the support of resets in movies, automatic savestates when threads are created to overcome the "thread list has changed" issue, the ability to lock individual inputs in the input editor (for multiplayer TASes).
The location of libTAS data files was moved from "~/.libtas" to $XDG_DATA_HOME/libtas/ and $XDG_CONFIG_HOME/libtas/ (usually ~/.local/share/libtas/ and ~/.config/libtas/), so you will loose your config files (or you can move them).
There are also a bunch of bug fixes, including fixing the freezes of the input editor. Some savestate crashes have been fixed (but not all, will it ever happen?)
See the full changelog.
Joined: 9/12/2014
Posts: 543
Location: Waterford, MI
Damn, this project has really grown over the last 2-3 years. I think its safe to say this is superior to hourglass at this point, despite having lower commits. Wine now partially works too. Something I didnt think would ever happen.
If I have a weak GPU (Intel HD Graphics 2500), does libTAS run, let's say, Shadow Warrior (Build engine) via DOSbox at 60 fps internally?
I know I have to do some tweaks to resolutions for both DOSbox and the game, but does libTAS provide hardware independence?
I don't mind running libTAS at <10 fps, but I want the video to be recorded at 60 fps for a game running on DOSbox.
TASing is like making a film: only the best takes are shown in the final movie.
Ambassador, Moderator, Site Developer, Player
(155)
Joined: 3/17/2018
Posts: 358
Location: Holland, MI
Yes as long as libTAS can run a game deterministically, no matter how slow your system is to render each frame it can sync to other machines and dump the optimal refresh rate.
It works in terminal, but not in libTAS. You still need to enter something valid in "Game executable".
At minimum, you need to specify the java binary itself as the game executable, and place -jar game.jar -path blahblah -silent etc. in command-line options. This is trivial if you take one second to actually think about what it actually means when you run a command: The first word you put in is the binary you're executing, everything else after that is just command-line arguments you provide to it.
At minimum, you need to specify the java binary itself as the game executable, and place -jar game.jar -path blahblah -silent etc. in command-line options. This is trivial if you take one second to actually think about what it actually means when you run a command: The first word you put in is the binary you're executing, everything else after that is just command-line arguments you provide to it.
Yeah, that was a nice catch! I ended up with this and... it worked. CL options are like you wrote (starting with -jar arg)
/usr/lib/jvm/java-1.11.0-openjdk-amd64/bin/java
TASing is like making a film: only the best takes are shown in the final movie.
