# libTAS gives Linux games frame advance and savestates, one process at a time

> libTAS is a GNU/Linux tool that injects itself into a running game to add frame advance, fast forward, pause and savestates for tool-assisted speedruns. It targets DRM-free Linux titles, with limited Wine support for Windows games, and the timing determinism it offers depends on the game and the OpenGL driver.

**clementgallet/libTAS** — GNU/Linux software to (hopefully) give TAS tools to games

- Repository: https://github.com/clementgallet/libTAS
- Stars: 597 · Forks: 77
- Language: C++
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/clementgallet-libtas

## A process injector, so the game has to be DRM free

libTAS is described on its own terms as GNU/Linux software to give TAS tools to games, and the code originates from SuperMeatBoyTaser. The mechanism is injection. Rather than emulating a game the way an emulator does, libTAS runs the real game as a Linux process and attaches to it, which is why the same approach works for any engine rather than only for a fixed list of titles. That same mechanism sets the boundary. The documentation says all of this only applies to games that do not have any active protection measure, and the guidance is to look for a DRM-free version of the game by default. Games installed through Steam may or may not work; some Steam games are in fact DRM-free and run without Steam being up, others need a few simple operations. For the rest, libTAS has a Virtual Steam client setting that implements a dummy Steam client, and the documentation is careful to say it does not support every game. That setting is a compatibility shim, not a bypass, and it is the first thing to check when a title refuses to start.

## The kernel and graphics stack are the real requirements

The stated system requirements are a GNU/Linux system with a recent kernel, at least 3.17, for the `memfd_create` syscall, and the supported architectures are `x86_64` and `x86`. The graphics requirement is more specific and easier to miss: you need the Mesa llvm OpenGL driver to support savestates for games using OpenGL. That is a driver-level requirement, not a setting in the interface, and it means that on a machine with a proprietary driver or a different OpenGL implementation, the core feature of the tool may simply be unavailable. The runtime dependency list is long and reflects what the tool does. It needs the core C runtime and the GCC and C++ runtime libraries, Qt 5.6 or newer with the core, GUI and widgets packages, the X11 and XCB libraries with keysyms and XKB support, Lua 5.4, ffmpeg, libcap, the file command, and the swresample, swscale and ALSA libraries in whichever version your distribution ships. Installing the Debian package pulls all of those in, which is the easiest route for a first attempt.

## Building from source and the dual-arch problem

A prebuilt Debian package exists and an automated build is offered for the last interim version, and a PKGBUILD is available on the AUR for Arch Linux. Building from source starts with the dependencies, and the README lists them as a Debian line beginning `apt-get install build-essential automake pkg-config` and running through the X11, XCB, Qt, Lua, ALSA, ffmpeg and libcap development packages, and an Arch line beginning `pacman -S base-devel automake pkgconf`. Then the source and the build script.

```bash
    git clone https://github.com/clementgallet/libTAS.git
    cd libTAS
```

```bash
    ./build.sh
```

Autoconf detects which libraries are present and disables the corresponding features if they are missing, so a partial environment gives you a reduced build rather than a failure. If you want a feature on or off deliberately, you add the flag at the end of the `build.sh` command. The rule that catches teams out is the architecture one: you must compile libTAS in the same architecture as the game, and if you have an amd64 system and only a i386 game, you cross-compile to i386. The dual-arch build handles the mixed case, producing an extra `libtas32.so` alongside the amd64 `libtas.so` and the GUI, and libTAS then picks the right library at runtime based on the game's architecture. That path needs 32-bit versions of the X11, XCB, ALSA and ffmpeg libraries, and a compiler set up for it, which on Debian means installing `g++-multilib`.

```bash
    cd build
    sudo make install
```

## Running it, and the three keys that matter

Once installed, libTAS is launched with the game executable and any command line arguments, either from a system menu shortcut or from a terminal.

```bash
    libTAS [game_executable_path [game_cmdline_arguments]]
```

The `libTAS -h` option prints a description of the program options. The program opens a graphical interface where you can start the game or change options, and the detail on each option lives on the tasvideos.org menu options page rather than in the README. The three defaults worth knowing are the ones you will use constantly. Frame advancing uses the `V` key, pause and play use the `pause` key, and fast forward uses the `tab` key. One detail is bolded in the documentation and catches first-time users out: the game starts up paused. That is deliberate, because a tool-assisted run needs a deterministic entry point, but it means a first launch looks like a hang until you unpause. The rest of the setup lives in a separate usage page, and the README itself points you there for the remaining details.

## Wine for Windows games, with the gaps named

There is initial support for running Windows games through Wine, and the documentation marks it with an important note: Wine support is limited and not being actively developed, and if possible you should use a Linux version of your game. The mechanics are specific. You need Wine installed and located somewhere in `$PATH`. For audio to be handled correctly you open winetricks, choose Select the default wineprefix, then Change settings, and check `sound=alsa`. In the game executable field you set the Windows `.exe`, both 32-bit and 64-bit being supported provided you have the matching Wine version, and libTAS detects a Windows executable and launches Wine with the right options. The known gaps are listed rather than hidden. The Prevent writing to disk feature does not work, because Wine delegates file handling to another process, the wine server, and that is tracked as issue #250. Window focus and unfocus do not work either. Between the two, the first one removes a safety feature that matters for a tool that manipulates game state, so a Wine workflow should be treated as experimental for anything where a corrupted save matters.

## What the repository contains, and what it says about the project

The repository layout is a conventional autotools project: `configure.ac`, `Makefile.am`, a `build.sh` wrapper, a `debian` directory for packaging, a `src` directory for the sources, a `test` directory, a `utils` directory, and a `.gitmodules` file for submodules. There is a `Dockerfile` that is worth a second look, because it reveals what the maintainer wants the tool to sit next to. It builds three things in separate stages on a Debian 12 base: ruffle, the Flash emulator, built from source with cargo; pcem, the PC emulator, configured with `--enable-release-build`; and libTAS itself, with the 32-bit architecture added via `dpkg --add-architecture i386` for the dual-arch case. The version arguments are left empty by default, with commented examples such as `RUFFLE_VERSION=nightly-2026-04-12` and `PCEM_VERSION=v17_13f53a2`, and the comments say these can be tags, commits, or branches. In other words, the Docker image is a container that gives you a TAS environment with the emulators most speedrunners need already built. The `libTAS.xcodeproj` directory points at macOS interest, but the documentation says the supported architectures are x86_64 and x86 on GNU/Linux, and for non-Linux users the recommendation is WSL 2, a Docker container, or a Linux virtual machine.

## Maintenance pace and the GPL terms

The release history shows v1.4.8 in May 2026, v1.4.7 in October 2025 and v1.4.6 in July 2024, and the last push to the repository was on 2026-09-28, so the tree is being worked on between tags. The version numbering staying in the 1.4 line for three years is a reasonable signal for a tool whose users depend on a stable behaviour, because a TAS tool that changed frame timing semantics would invalidate existing movies. The licence is GPL-3.0, and the repository carries a COPYING file. For running the tool on your own machine that imposes nothing. For anyone who wants to redistribute a modified build, or to embed parts of it in another project, the copyleft obligations are real and are the kind of thing to think about before shipping. The project also has an official website, a Discord server and additional documentation on tasvideos.org, and the README describes the website as still in progress, so the tasvideos.org pages are where the substantive documentation currently lives, including the game compatibility list and the usage notes.

## Conclusion

Adopt libTAS if you make tool-assisted speedruns of DRM-free Linux games and you need frame advance and savestates that a screen recorder cannot give you. Skip it if your game has active protection, if you need Windows titles, since the Wine path is limited and not being actively developed, or if you need savestates in an OpenGL game without the Mesa llvm driver. Before you commit, check the game compatibility page for your title, build the 32-bit variant if you also run i386 games, and expect to read the usage notes on tasvideos.org rather than the README alone.

## FAQ

### What operating system and hardware does libTAS need?

A GNU/Linux system with a recent kernel, at least 3.17 for the `memfd_create` syscall, on `x86_64` or `x86`. The Mesa llvm OpenGL driver is required to support savestates for games using OpenGL.

### Which keys control libTAS during a game?

The `V` key advances a frame, the `pause` key toggles pause and play, and the `tab` key fast forwards. The game starts up paused.

### Can libTAS run Steam games?

Some of them. The documentation says to look for a DRM-free version of a game by default, and that some Steam games are in fact DRM-free and work without Steam running. For the others there is a Virtual Steam client setting that implements a dummy Steam client, but it does not support every game.

### How do I build a 32-bit libTAS alongside a 64-bit one?

Build with `./build.sh --with-i386`, which produces an additional `libtas32.so` library next to the amd64 builds. You also need 32-bit versions of the X11, XCB, ALSA and ffmpeg libraries, and a compiler able to cross-compile, such as `g++-multilib`.

## Sources

- [clementgallet/libTAS on GitHub](https://github.com/clementgallet/libTAS)
- [Issues](https://github.com/clementgallet/libTAS/issues)
- [License: GPL-3.0](https://github.com/clementgallet/libTAS/blob/master/LICENSE)
- [README](https://github.com/clementgallet/libTAS/blob/master/README.md)
- [Releases](https://github.com/clementgallet/libTAS/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/clementgallet-libtas