digdib schrieb:
@flaphoschi Ich glaube native AAA(+A für Ubisoft) Spiele für Linux werden wir nie erleben. Dann wohl schon eher für MacOS. Unter Windows müssen die Entwickler schon so einiges an Hardware und Treiber-Kombinationen beachten. Unter Linux wird das ja alles nur noch schlimmer, noch mehr Treiber und dazu noch verschiedene Kernel Versionen. Schau dir mal die ganzen Linux Ports von Feral Interactive an, die meisten davon sind keine zehn Jahre alt. Und auf ProtonDB wird empfohlen lieber die Windows Version + Proton zu nutzen. Da man die Linux-Versionen kaum noch zum laufen bekommt, da die auf längst veraltete Libs setzt. Den Aufwand bindet sich niemand mehr ans Bein.
Das ist auch immer der gleiche Fehler. Deswegen hat Valve den Entwicklern die Native-Linux-Runtime bereitgestellt.
Was machen die Windowsentwickler? Die legen ihre Bibliotheken immer bei. Kostet mehr Speicher, Bugfixes fehlen. Aber sie haben Ihre Ruhe. Die Ganzen Runtime-Libraries (C++ Redistibutable) hätte Windows auch.
Und macOS erzwingt es mit den App-Bundles regelrecht. Wobei Apple halt nicht auf Komptiblität setzt. Die haben mehrmals alles verworfen (Carbon/Quartz), die Permissions, PowerPC, Intel und nun Apple Silicon. Wenn es ein neues Major-Release gibt, warten unter macOS erstmal alle auf Updates.
Von Linux gibt es auch noch das Angebot es mit Flatpak zu automatisieren.
Wenn man sich als Entwickler dann eine komische quellgeschlosse Bibliothek eintritt, die andere Bibliotheken linkt, die keine stabile ABI versprechen - muss man seine Zeug komplett abliefern. Ist nicht effizient, aber so läuft es auf jedem System.
Die schlauen Entwickler packen ihre Bibliotheken in das Verzeichnis der Executable. Die schlauen haben auch oft ein Shellscript mit “LD_BLUBB”. Wenn möglich linkt man gleich statisch. Und es ist kein Verbrechen den Quellcode seiner Bibliotheken zu haben und selbst zu kompilieren. Wenn man dagegen die “Was auch immer” von einer Klitsche linkt, die wiederum SDL1 und OSS verwendet…schwierig? Bei Pipewire und Konsorten wir extra darauf geachtet, dass das all die alten APIs/ABIs hat.
Die Prinzipien sind unter Linux, macOS und Windows gleich. Eine gutes Warnsignal ist immer, wenn im Verhältnis viele Shellskripts dabei sein und selbst disributionsspezifische Pakete gebaut werden. Wenn “Redistribution” erlaubt wird und sich die externen Abhängigkeiten auf Mesa und vielleicht Libc/Libstdc++ beschränken ist es eher gut. SDL würde ich als quellgeschlossenes Spiel schon direkt mitliefern.
“Es läuft nicht mehr” sollte gefolgt sein von der Frage was falsche gemacht wurde.
Der Schmerz bei mir war die Distribution auf Windows und macOS. Windows war nur viel Aufwand. Und macOS ist ein Minenfeld ohne XCode.
PS: Der größte Kahlschlag war iOS? 32 Bit Kompatiblität weggetreten. Wenn es den Entwickler nicht mehr gab? Pech. Und leider ist selbst unter Windows die Ausführung von Programmen aus dem Jahr 2000 ein Problem.
Das Performance-Problem betrifft ja erstmal nur DirectX12 bzw VKD3D Spiele, das sind aber halt die meisten aktuellen Titel. DirectX11 bzw Vulkan Titel haben das Problem in der Regel nicht. Wobei da auch nicht immer alles Rund läuft. Beim Aktuellen Indiana Jones musste man auch ziemlich basteln, um das gut zum laufen zu bekommen. Kurz zusammengefasst würde ich sagen, ja AMD läuft besser aber Nvidia läuft bei weiten nicht so schlecht, dass ich davon abraten würde. Ich habe bis jetzt alles zum laufen bekommen, hier und da, in meinem Fall besonders Cyberpunk 2077, fehlen halt ein paar Fps im Vergleich zu Windows. Aber in 4k mit DLSS4 Performance ist das zum Glück kein großes Problem mehr.
(um mal die Zukunftsmusik im Luftschloss voll aufzudrehen) Vereinzelt gab‘s sowas aber schon.
