Needs of gstreamer libraries in sniper #748
Comments
saif-ellafi
changed the title
|
Update: current work around
|
|
Ok it wasn't so simply to drop dependencies, I went back to dependencies, and switched back to runtime 1.0. This "seems" to be working fine |
|
@saif-ellafi does this technique allow you to ship a game for SteamOS, or would you need to compile the libraries a different way for that - for example for the Steam Deck |
Unfortunately no, it doesn't. The title will not pass the compatibility testing review process for Steam Deck and only the Windows version will be considered. Relying on users setting the 'Legacy Runtime 1.0' compatibility tool and installing additional libraries on their host is a burden on the user, it is fragile and will not work reliably across distributions or OS updates, which is why it should be avoided. Native titles built towards Steam for Linux should be compiled against the Steam for Linux SDK. Documentation for game developers is available at https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md |
The Steam Runtime intentionally does not provide GStreamer. The problem with GStreamer is that it doesn't do anything directly useful on its own: it's a plugin-based system, and various plugins require additional libraries (for example for audio and video codecs). If we started adding all the plugins that anyone might want, we'd quickly run into problems with runtime size and complexity. If you bundle your own copy of GStreamer with your app, you will probably also need to build some GStreamer plugins for the formats you want to be able to play, include those too, and set environment variables to tell your app how to find those plugins (such as Alternatively, if the only thing you want to do is to play audio clips, perhaps you could use SDL2_mixer (which we do include), or use a lower-level audio library directly? We provide GStreamer is probably only worth it if you need to be able to play unusual audio formats, or deal with videos or audio/video recording.
Expanding on this a bit: By default, Steam runs games a container, either "Steam Linux Runtime 1.0" or "Steam Linux Runtime 3.0" depending on how you have configured your game. Most libraries that come from the host system are not available in this container, even if the user has them installed on the host. This might seem counterintuitive, but it's deliberate: it's the same design principle as Flatpak. We want to make sure that if your game works today, there's a good chance that it will still work in 10 years' time, with no special workarounds required from users. If you rely on libraries from the host system, then that isn't going to be true (or, at least, not reliable), because the host system is a constantly moving target. Valve is particularly strict about doing this when doing compatibility testing for the Steam Deck, because the Steam Deck's operating system is a fast-moving "rolling release", so the libraries that it ships next year will probably not be compatible with the libraries that it ships today. But we want Steam games to keep working for longer than that, and that's where the Steam Linux Runtime comes in.
Unfortunately this term is ambiguous: I can't immediately tell whether you mean "Steam Linux Runtime 1.0" (good) or "Legacy Runtime 1.0" (not good). "Steam Linux Runtime 1.0" is a container, intended for backwards compatibility with semi-old games, with relatively strict dependency handling. For historical reasons (to avoid breaking older games), it is the default. If your game works well enough with this runtime, it can pass compatibility testing review for Steam Deck. "Legacy Runtime 1.0" is the legacy non-container-based environment, again intended for semi-old games. Games running in this environment will randomly work or not work, depending on what libraries the user happens to have installed on their host system. Users can use it as a workaround for older, mis-packaged games that are missing some of their required libraries (like #751), but games that rely on this runtime cannot pass Steam Deck compatibility testing. For new apps/games where you do not have backwards compatibility concerns to worry about, what I would recommend targeting is "Steam Linux Runtime 3.0" (internally codenamed
I'm guessing that you are probably using a Flatpak runtime that already includes GStreamer and a wide range of plugins? The various branches of the Steam Runtime do not have exactly the same list of supported libraries that Flatpak runtimes do. |
Dear steam-runtime team,
I hope this issue does not bring trouble, I really tried to read as much as I could.
I am a new indie-single game developer, trying to get my game working on Steam natively on Linux. The game is very simple, and developed in Flutter, runs in Windowed mode.
However, it needs to play audio, and the current dependency makes use of
libgstreamer1.0-devandlibgstreamer-plugins-base1.0-devto run, which are typically available in host systems (but not always).I am personally fine with asking users to install these libraries, however I wish I could bundle a safe container. I tried a few things but no success, for example packing the .so files in a directory, and running the game from a script that appends the
LD_LIBRARY_PATH.However all of this put me in an endless loop of trial and error, ultimately getting me stuck in
Which could either mean I am getting closer to a solution, or that I am in a tunnel without light at the end of it :)
Any advice is welcome, I am trying hard not to run my app on proton.
Alternative 2: I could be fine to not provide this library and ask users to install these on their host. But how should I package my game then? Would sdk 1.0 do this?
Alternative 3: My app works in the form of a Flatpak, if ever could Steam run a flatpak container instead of a native runtime?
Best regards
Saif
The text was updated successfully, but these errors were encountered: