Bericht Avatar unter Linux im Test: Ein Ausflug nach Pandora muss noch warten

[Tanzmusikus]

@Termy
Danke für die Korrektur!

 

[VikingGe]

AMD Fluid Motion Frames alias Frame Generation funktionierte unter Linux leider (noch) nicht, die Option war schlichtweg ausgegraut.

Ist mal wieder so ein Fall, wo das Spiel Third-Party-Libraries benutzt, um die GPU-Architektur abzufragen.

Frame Generation lässt sich von Hand über die Konfigurationsdatei aktivieren (innerhalb des Wine-Prefixes:
/drive_c/users/steamuser/Documents/My Games/AFOP/graphics settings.cfg), indem man einfach
frameGeneration = false zu true ändert. Dann hat man im Menü witzigerweise eine Option, die zwar aktiviert, aber immer noch ausgegraut ist.

Ab davon hatte ich mit einem etwas anderen Setup hier (Lutris, irgendein Wine-GE-Build, halbwegs aktueller mesa-git-Build auf ner 6900XT) bislang auch keine Abstürze, habe aber zugegebenermaßen auch noch nicht weit gespielt.

 

[Tanzmusikus]

@Kaito Kariheddo
Diese Info von @VikingGe könnte wichtig sein!
Vielleicht läuft's dann bei dir auch zuverlässiger.

@VikingGe
Du kannst das Spiel also unter Linux spielen.
Welche Konfig benutzt Du (Lutris, HGL, Steam, ...?) zusätzlich zu Wine-GE-Custom (z.B.: "Wine-GE-Proton8-25")?

 

[Beelzebot]

Es ändert trotzdem nichts an meiner Kernaussage, dass Linux auf dem Desktop Nische ist.

Ich verstehe einfach nicht, warum das überhaupt ein Problem sein soll
Ist mir doch sowas von egal, wer was für welche Plattform entwickelt, Hauptsache, ich kann auf meinem Arch alles Zocken was ich will. Und das streckenweise mit mehr Performance als unter Windows, die Tests zeigen es doch!
Ich kapier nicht, was du davon hast, den Leuten, die auf Linux spielen wollen, ihre Gaming-Erfahrung madig machen zu wollen? Vor allem kommt in den letzten Jahren richtig Bewegung in einige Sachen, weil kontinuierlich mehr Nutzer dazu kommen.
Aber tue dir keinen Zwang, geil dich an den zwei Prozent auf, wenn dich das glücklich macht

 

[sardello]

der test zeigt es ja: der nvidia treiber ist nicht alt, dennoch stürzt das game ab. mit amd läuft es, allerdings von der performnace und frametimes noch nicht da wo es sein sollte...

Es gibt ja Gerüchte, dass der Nvidia-Treiber gerade wegen eines bald anstehenden Nintendo Switch 2-Releases derzeit große Fortschritte macht. Wäre aber eigentlich nur logisch, die Arbeit an die Linux-Community weiterzugeben.

 

[Kaito Kariheddo]

Ab davon hatte ich mit einem etwas anderen Setup hier (Lutris, irgendein Wine-GE-Build, halbwegs aktueller mesa-git-Build auf ner 6900XT) bislang auch keine Abstürze, habe aber zugegebenermaßen auch noch nicht weit gespielt.

Hattest du was an den Grafikeinstellungen geändert ? Bei mir lief es ab Start auch erstmal ohne Probleme, das Spiel hatte aber auch automatisch alles auf Niedrig gestellt gehabt.

Und du hast nicht zufällig eine Erklärung für die unregelmäßigen Frametimes wenn das Spiel die GPU voll auslastet ?^^ In anderen Spielen mit dem Problem und auch hier werden die wieder gut sobald ein Framelimit gesetzt wird.

 

[schM0ggi]

Du meinst bestimmt diesen Beitrag:

Nein, den hier:

Die verschiedenen Distros sind relativ egal, es geht nur darum wie aktuell die installierte Software ist, ansonsten ist alles was relevant ist fürs gaming ohnehin bei allen gleich.

Durch die Steam Runtime Container (Native und Proton) wird das Problem reduziert, weil viele basis libs darin enthalten sind, so können Entwickler sicher sein, das diese auch in der richtigen Version vorhanden sind.

Eigentlich könnte Valve diese Runtime soweit ausbauen, das alles notwendige bis auf den Linux Kernel darin enthalten sind. Dann müssten Entwickler nur noch auf die Kernel und Runtime Version welche unterstützen werden sollen achten.

Das habe ich dann aufgegriffen und in den Raum geworfen, dass eine Art Runtime, unabhängig von Steam/Valve, für allgemeines Linux Gaming in einer Art Gemeinschaftsprojekt doch eine gute Idee wäre. Also direkt von den Distro Anbietern und/oder Linux Maintainern und nicht von App Entwicklern wie Lutris etc., wo dann wieder jede sein eigenes Süppchen kocht.

Du meinst doch die "Soldier-Runtime" von Valve. Das müsste die Steam-Runtime für Windows-Spiele sein.
Die Steam-Runtime für Linux-native Spiele heißt m.W. "Scout".

Scout, Soldier, Sniper. Mittlerweile 3 Versionen die unterschiedliche Stände der Bibliotheken aufweisen und, meine ich in Erinnerung zu haben, von Debian kommen. Diese werden auch für Proton verwendet. Das wird ja dann alles in dieser Container Technologie in Steam gesandboxed.

Wenn es mit Proton geht, warum dann für nativ nochmal extra was am Spiel werkeln? Ich hab die Erfahrung gemacht, dass es eher nativ Probleme gibt, als mit Proton. Und ich nutze auch Wine-GE-Custom für alle Spiele, die nicht bei Steam sind. Funktioniert bisher tadellos. Avatar hab ich aber nicht getestet. ^^

Ja, das ist noch mal ein anderes Thema. Warum native Linux games wenn es mittlerweile mit Wine/Proton in der Regel sehr gut funktioniert usw. Darüber wollte ich gar keine Diskussion anfangen.

 

[Tanzmusikus]

LW-Run gibt's übrigens auch. Kannte ich noch gar nicht.

 

[Tevur]

Schön, dass es hier doch mal wieder um das Spiel selbst geht.

Ich hab tatsächlich noch kein Ubi Connect oder ein Ubisoft-Spiel gespielt, seitdem ich auf EndeavourOS gewechselt bin.
Mein erster Troubleshoot wäre erstmal, das UbiConnect-Overlay zu deaktivieren, sowas hat früher schon, auch unter Windows, gerne mal ein Problem gelöst.

 

[Tanzmusikus]

Und du hast nicht zufällig eine Erklärung für die unregelmäßigen Frametimes wenn das Spiel die GPU voll auslastet ?^^ In anderen Spielen mit dem Problem und auch hier werden die wieder gut sobald ein Framelimit gesetzt wird.

Denuvo / RayTracing-Optionen geändert ? 😉

 

[VikingGe]

Hattest du was an den Grafikeinstellungen geändert? Bei mir lief es ab Start auch erstmal ohne Probleme, das Spiel hatte aber auch automatisch alles auf Niedrig gestellt gehabt.

Ja, hab erstmal alles auf Ultra gedreht und dann ein paar Optionen wieder runter für bessere Performance, ging problemlos.

Was die miesen Frametimes angeht - keine Ahnung, wirklich glatt sind die hier auch nicht.

Edit: @Tanzmusikus:

Abgesehen von vkd3d-proton ist das nicht wirklich aktuell, das ist einfach irgendein Uplay-Setup von vor ein paar Monaten.

 

[TheHille]

Schön, dass es hier doch mal wieder um das Spiel selbst geht.

Ich hab tatsächlich noch kein Ubi Connect oder ein Ubisoft-Spiel gespielt, seitdem ich auf EndeavourOS gewechselt bin.
Mein erster Troubleshoot wäre erstmal, das UbiConnect-Overlay zu deaktivieren, sowas hat früher schon, auch unter Windows, gerne mal ein Problem gelöst.

FarCry5 läuft so ziemlich ootb bei mir unter Endeavouros, AC Odyseey ist leider "nomen est omen" eine vergebliche Odysee.

Gestestet über Lutris, Ubisoft-Launcher.

 

[Kuristina]

Ich hab tatsächlich noch kein Ubi Connect oder ein Ubisoft-Spiel gespielt, seitdem ich auf EndeavourOS gewechselt bin.

The Division 2 und Anno laufen auch butterweich. ^^

 

[JustAnotherTux]

@Tanzmusikus @schM0ggi

Ich weiß nicht ob es wirklich einen neuen Standard bräuchte.
Es gibt ja linux container (LXC), docker, containerd und flatpak.

Um genau zu sein geht flatpak steam ja schon in die Richtung weil Mesa auch in der Flatpak Runtime unabhänig vom System installiert werden kann.
(Hatte ich auch schon verwendet und das funktioniert auch relativ gut nur hängt Flatpak Mesa manchmal einfach zu weit hinerher, es braucht wohl mehr Maintainer)


Was ich meine ist praktisch ein vorkonfigurierter LXC linux container welcher auch die Userspace Treiber und den X Server enthält, das sollte auch bereits funktionieren.

Also ähnlich wie normale linux container oder docker oder containerd verwendet werden aber eben auch noch den GUI Part mit enthalten (Also Userspace treiber und X Server oder Wayland compositor z.B. gamescope (nicht mode ) https://github.com/ValveSoftware/gamescope, pipewire / pulseaudio ... ).

Für docker container gibt es auf Github auch ein Projekt dafür, das hatte ich auch mal ausprobiert allerdings ist das für die meisten zu experimentell:
https://github.com/mviereck/x11docker

Schade eigentlich das es bisher kein Interesse dafür gibt das größer aufzubauen, eigentlich brauchen wir nur ein Projekt welches vorkonfigurierte LXC container anbietet welche wir dann z.B. in Lutris integrieren können.

Wenn ich mal genug Zeit habe und es noch niemand umgesetzt hat könnte ich mir das als Freizeitprojekt vorstellen.

 

[JustAnotherTux]

Für docker container gibt es auf Github auch ein Projekt dafür, das hatte ich auch mal ausprobiert allerdings ist das für die meisten zu experimentell:
https://github.com/mviereck/x11docker

Schade eigentlich das es bisher kein Interesse dafür gibt das größer aufzubauen, eigentlich brauchen wir nur ein Projekt welches vorkonfigurierte LXC container anbietet welche wir dann z.B. in Lutris integrieren können.

Wenn ich mal genug Zeit habe und es noch niemand umgesetzt hat könnte ich mir das als Freizeitprojekt vorstellen.

Bzw. warum das Rad neu erfinden, ich versuche mich demnächst noch mal an x11docker, sollte eigentlich nicht so schwer sein das offizielle docker archlinux image entsprechend zu erweitern und dann mit x11docker zu verwenden im ideal Fall dann mit gamescope.

 

[foofoobar]

@Sron
Es geht in Richtung des Henne-Ei-Problems: Der Spieler installiert kein Linux, weil er nicht weiß, ob seine Spiele unter Linux überhaupt und wie gut laufen. Sind diese Informationen einfacher zu finden, entschließt er sich (hoffentlich) eher, auch mal unter Linux zu zocken.

Kann sich den sicher sein das bestimmte Spiele unter Windows laufen?

 

[Pummeluff]

Schade eigentlich das es bisher kein Interesse dafür gibt das größer aufzubauen, eigentlich brauchen wir nur ein Projekt welches vorkonfigurierte LXC container anbietet welche wir dann z.B. in Lutris integrieren können.

Die Idee ist gar nicht so intelligent, wie sie erscheint.

Ich hatte vor 3 oder 4 Jahren mal damit rumgespielt. Hab einen Docker-Container aufgesetzt auf Basis von Debian 10 (dürfte damals die Basis für Steam-Spiele gewesen sein).

Ziel war:
x86_64-reines, sauberes Hostsystem ohne 32bit-Multilibs. Im Container sollten dann die ganzen (alten) Libs stecken, die die Spiele so brauchen.

Die Probleme:
Du musst die Devices durchreichen. Die Grafikkarte hab ich noch geschafft. Allerdings stimmen UID/GID vom Hostsystem logischerweise nicht mit den IDs im Container überein. Aber glxgears funktionierte.

Die Probleme gingen dann beim Sound richtig los. Damals hatte ich noch Pulse-Audio. Einige Spiele, z.B. Tombraider setzen nativ auf Pulseaudio. Der Sound per reinem Alsa wollte gar nicht. Pulseaudio benötigt dann wiederum DBus, der mit diversen Sockets arbeitet und zudem noch ein Systemd-Dienst ist. An der Stelle bin ich dann ausgestiegen. Das hab ich im Container einfach nicht zum Host verlinkt bekommen.

Weitere Überlegungen
Ein weiterer Grund für den Container war auch, dass Steam dann unter dem eingeloggten User läuft. Ist der Steam-Client böse, kann er ziemlich viel Mist mit den lokal vorhandenen Daten anrichten und potentiell schnüffeln. Sinnvoller wäre da, den Steamclient + Lutris entweder unter einem separatem User oder in einem chroot laufen zu lassen. Ist beides möglich, aber erfordert auch ein Wissen + Aufwand, den die meisten Nutzer wohl eher nicht investieren wollen.

Schließlich und endlich hab ich mich dann der Bequemlichkeit ergeben:

• Linux-Spiele: Ich hab mir je einen lib32- und einen lib64-Ordner angelegt, in dem die benötigten Libs reinkommen, die die Spiele nicht mehr im System finden. Den bind ich dann über LD_PRELOAD ein. Lutris bietet das in den Runneroptionen bequemerweise an.
• Windows-Spiele: Jedes Spiel bekommt einen eigenen WINEPREFIX. Das macht Lutris auch von Hause aus schon so. Damit kann man für verschiedene Windows-Spiele auch verschiedene Proton-Versionen und Windows-Einstellungen verwenden. Und beim Löschen bleibt auch kein Müll zurück.

 

[longusnickus]

@Sron
Es geht in Richtung des Henne-Ei-Problems: Der Spieler installiert kein Linux, weil er nicht weiß, ob seine Spiele unter Linux überhaupt und wie gut laufen. Sind diese Informationen einfacher zu finden, entschließt er sich (hoffentlich) eher, auch mal unter Linux zu zocken.

Es geht mir auch nicht nur um Linux. Ich finde, MacOS sollte auch betrachtet werden.

das meiste ist auf protondb. 10000+ spiele haben auch schon einen hinweis auf der steamseite selbst. zusätzlich gibt es auch protondb addons für browsers und dann sieht man die bewertung auf der steamseite der jeweiligen spiele
leichter geht kaum noch

henne-ei problem war es vor proton. da war es wirklich so, dass entwickler nicht für linux programmierten, weil es zu wenig nutzer waren und es waren zu wenig nutzer, weil keine linux spiele kamen

man muss heute wirklich nur noch auf sehr wenige spiele verzichten auf linux.

Generell hatte ich mit Ubisoft spielen unter Linux oft Probleme.
Während sonst fast Spiele über Steam und Lutris sauber liefen. (Selbst titel die unter Windows 10 Probleme gemacht haben weil sie älter waren)

AC Odyssey läuft gar nicht bei mir.

bei mir läuft odyssey problemlos.
dieser uplay müll ist aber wirklich ekelhaft. proton experimental ist pflicht und dieses MTU problem gibt es glaube ich auch noch
aber in diesem test startet das spiel ja, also liegt es eher nicht am client

Das geht nicht so einfach. Die Programme müssen schon irgendwie mit dem Betriebssystem kommunizieren und genau dieser Punkt ist bei jedem OS anders.

es gibt aber plattformübergreifende kommunikationen wie eben VULKAN!
ein VULKAN spiel muss von proton nicht übersetzt werden. das wird einfach durchgereicht an das BS. und der grafikteil ist nunmal der anspruchsvollste bei spielen. wenn das wegfällt, dann hat man schon viel gewonnen

ich kann mich da noch an ein interview von einem ID entwickler erinnern, der meinte, dass sie DOOM 2016 (was ja vulkan hat) einfach mal zum spaß für linunx kompiliert haben und es fast problemlos funktionierte, aber bethesda wollte das so nicht veröffentlichen, weil ja immer was sein könnte und sie das nicht supporten wollten

auf offene standard setzen ist sehr von vorteil.
ich kann mich noch an die anfänge von proton erinnern als dieses Media Foundation zeug nicht funktioniertt hat, weil es von MS kam. da wurde dann irgendwie eine offene alternative entwickelt, aber bis dahin funktionierten viele VIDEOS in spielen einfach nicht. da war dann im besten fall schwarzbild. manchmal blieben die spiele auch einfach hängen.

Q.U.B.E. 10th Anniversary ist ein aktuelles bsp. das funktioniert mit proton ohne handanlegen nicht, weil da wieder irgendwas von MS drinnen ist.

Wenn es mit Proton geht, warum dann für nativ nochmal extra was am Spiel werkeln? Ich hab die Erfahrung gemacht, dass es eher nativ Probleme gibt, als mit Proton.

das kommt ganz auf die entwickler und deren können an!
es gibt halt sehr viele bsp.
das neue monkey island zB.... und generell viele indie spiele. da sitzen meisten nur wenige entwickler und trotzdem bringen die eine saubere linux version raus. stardew, baphomets fluch, valheim, superliminal, aragami,....
und anspruchsvolle spiele wie metro exodus
es war für 4A games finanziell sinnlos metro für linux rauszubringen, aber sie taten es einfach, weil sie lust hatten. und die native version läuft auch besser als mit proton.

 

[JustAnotherTux]

Die Idee ist gar nicht so intelligent, wie sie erscheint.

Ich hatte vor 3 oder 4 Jahren mal damit rumgespielt. Hab einen Docker-Container aufgesetzt auf Basis von Debian 10 (dürfte damals die Basis für Steam-Spiele gewesen sein).

Nun es geht schon, selbst habe ich nicht viel gemacht aber mit x11docker hatte es vor ein paar Jahren funktioniert. https://github.com/mviereck/x11docker

IMO geht es eher darum für Entwickler eine einheitliche Basis bereit zu stellen welche auf allen anderen Distros läuft und dann kann darauf Optimiert werden, die Distro der User ist dann weniger relevant.

Wobei das eigentlich auch schon durch Flatpak Mesa + Steam Runtime gegeben ist.

 

[Kuristina]

und die native version läuft auch besser als mit proton

Es gibt immer Einzelbeispiele auf beiden Seiten. Ich hab über 80 Spiele bei gog und die kann man ja da auch einzeln runterladen. Da gibts auch ab und an eine Linux Version. Und bisher hatte ich da eher Fehlschläge dabei, als bei den Windows Versionen, die mit Proton sofort liefen. Aber Erfahrungen sind ja unterschiedlich.

das kommt ganz auf die entwickler und deren können an!

Das stimmt natürlich. Und auf Lust und Zeit und Geld. ^^