Von schmidicom am Di, 1. September 2015 um 11:29 #
Irgendwie kann ich mir nicht wirklich vorstellen dass das Programmieren unter/für Linux so viel schwerer sein soll als unter/für Windows, zumindest nicht wenn der Wille dafür auch wirklich vorhanden ist.
Von schmidicom am Di, 1. September 2015 um 12:16 #
Support muss man eigentlich nur aufwenden wenn der Code fehlerhaft ist, also war die Portierung für sie entweder doch nicht so einfach wie behauptet oder sie haben sich dabei einfach nicht wirklich viel mühe gegeben. Und um genau diesen Widerspruch ging es mir in meinem Kommentar.
"Support muss man eigentlich nur aufwenden wenn der Code fehlerhaft ist"
Es gibt viele Gründe, warum sich Spieler an einen Hersteller wenden, dabei muss die Ursache keineswegs ein Fehler im Spiel selbst sein. Wenn ein User an seinem System rumbastelt (was bei Linux ja nun mehr als wahrscheinlich ist), und dabei Fehler verursacht, dann können dabei Probleme entstehen, die mit dem Spiel nichts direkt zu tun haben, aber dort dann wiederum zu Fehlern führen. Solche Fehler zu finden kostet die Hersteller viel Zeit, und erzeugt umso mehr Frust, umso weniger sie mit dem Spiel selbst zu tun haben.
Da Linux eine extrem heterogene Umgebung ist, ist die Wahrscheinlichkeit für Probleme durch das Zusammenspiel von Komponenten entstehen, sehr hoch.
Zumal einige User eben auch dazu neigen, Änderungen am Basissystem durchzuführen, deren Konsequenzen sie nicht überblicken können. Bei Linux ist so etwas weit leichter und häufiger als bei Windows zu finden.
Dazu kommen teils noch eher maue kommerzielle Treiber bei Linux, welche die Sache auch nicht leichter machen.
Nur wie passt das mit der noch höheren Supportquote von MacOSX zusammen, die im Artikel erwähnt wird? Weil das läuft auf - homogener Hardware als - homogene Software
Natürlich könnte man (da es auch ein *unix* ist) dort (in Grenzen) auch Änderungen an der Basiskonfiguration vornehmen, aber welcher Apple-User macht das schon?
Die Probleme mit OSX liegen wahrscheinlich daran, dass die Mehrheit der Mac-Benutzer "nur" einen Intel-Grafikchip verbaut hat (Über 95% der Macs sind Notebooks) und das bei Windows-Spielern eher selten der Fall ist.
Und so heterogen wie es immer dargestellt wird, ist die Mac-Landschaft auch wieder nicht.
Auf Grund des hohen Preises, sind Macs im Durchschnitt länger im Einsatz als ihre Windows-Pendants. Dazu kommt, dass Apple die Angewohnheit hat die Notebooks jedes Jahr mit CPU -und Chipsatz-Updates zu versehen.
Vom MacBook Air gab es seit 2011 vier Versionen und mit ziemlicher Sicherheit kommt dieses Jahr noch eine dazu:
2011 - Sandybridge-CPU mit HD3000-GPU (Max. OpenGL 3.3) 2012 - Ivybridge-CPU mit HD4000-GPU (Max. OpenGL 4.0) 2013 - Haswell-CPU mit HD5000-GPU (Max. OpenGL 4.3) 2014 - Broadwell-CPU mit Iris Pro-GPU (OpenGL 4.4) 2015(?) - Skylake-CPU mit Iris Graphics 5xx
Wenn die Entwickler jetzt ein Windows-Spiel portieren, dass massiv Gebrauch von DirectX11-Features macht, müssen sie entweder auf diese Features verzichten oder den Anwendern Einschränkungen bezüglich der Hardware aufzwingen (z.B. nur ab Intel HD5000).
Da viele Mac-Anwender auf Grund des identischen Äußeren gar nicht wissen, welche Hardware jetzt explizit verbaut ist, kaufen sie vielleicht ein Spiel um dann zu merken, dass ihre Hardware zu alt ist (Weil sie z.B. ein 2013er MacBook Air haben). Was macht man dann? Man wendet sich an den Support.
"Wenn die Entwickler jetzt ein Windows-Spiel portieren, dass massiv Gebrauch von DirectX11-Features macht, müssen sie entweder auf diese Features verzichten oder den Anwendern Einschränkungen bezüglich der Hardware aufzwingen (z.B. nur ab Intel HD5000)."
Das Problem ist doch genauso unter Windows vorhanden. Da haben auch nicht alle Leute den gleichen Prozessor.
Unter Windows ist es auch eher üblich, dass man als Spieler weiß, welche Hardware verbaut ist. Zudem ist der Anteil der Spieler mit Notebooks deutlich niedriger als unter OSX.
Dazu kommen unter OSX noch Sachen wie die Retina-Displays, die in der Windowswelt bisher kaum vorkommen.
Dazu kommen unter OSX noch Sachen wie die Retina-Displays, die in der Windowswelt bisher kaum vorkommen.
Eigentlich ist es eher umgekehrt. Nachdem man wohl kaum noch ein Android-Handy oberhalb der Einstiegsklasse ohne Display feiner als Retina verkaufen kann, gibt es bei Windows-Notebooks gefühlt entweder nur noch in super billig mit veralteter Auflösungen (das gibt es von Apple erst gar nicht) oder es muss besser als Retina sein, sobald man auch nur in die Nähe der Preisregion von Apple-Geräten kommt.
Gerade mal bei 'nem Anbieter die Notebookseite aufgerufen. Zu den Top-Sellern gehören (laut deren Aussage) das MSI GE62-2QFUi716H11 mit 3.840 x 2.160 Pixeln auf 15,6" und das Asus UX305FA-FB033H mit 3200 x 1800 auf 13,3" ... usw... und noch mehr oberhalb der Retina-Klasse.
Ne, das ist nichts ungewöhnliches mehr. Den Stein hat Apple ins Rollen gebracht und die Anbieter sind - sinnvoll oder nicht - auf den Zug aufgesprungen. Das ist auch in der Windows-Welt nichts ungewöhnliches mehr.
Allerdings dürfte die Bildschirmauflösung wohl bei Spielen, im Gegensatz zu so Dingen wie dem alten Windows XP-Desktop mit seiner festen Pixelausrichtung, sowieso kaum Supportanfragen auslösen. Da ist es doch schon immer üblich, die Spieleauflösung von der realen physischen Auflösung zu entkoppeln.
Dazu kommen teils noch eher maue kommerzielle Treiber bei Linux, welche die Sache auch nicht leichter machen.
Reden wir besser nicht von "kommerziell" sondern von "proprietär". Kommerziell impliziert nämlich, dass die Hersteller Geld für die Treiber wollen.
Treiberprobleme unter Linux bei Spielen treten in der Regel wegen zwei Dingen auf:
Der Benutzer setzt den proprietären Catalyst-Treiber von AMD ein.
Der Benutzer setzt einen quelloffenen Treiber ein, der nicht alle benötigten OpenGL-Features unterstützt
Ich kenne eigentlich keinen Spielehersteller unter Linux, der jemals ein Problem mit dem proprietären Nvidia-Treiber hatte.
Neben diesen beiden Problemen gibt üblicherweise nur dann Probleme, wenn ein Anwender das Spiel unbedingt auf einer nicht offiziell unterstützten Distribution spielen will.
Von schmidicom am Di, 1. September 2015 um 13:58 #
Eine solche Haltung seitens Spielentwickler ist zwar nett aber wohl kaum praktikabel.
Nur so als Beispiel: Ich glaube kaum das es Google groß interessieren würde wenn in deren Chrome das WebGL nicht das macht was es soll nur weil die OpenGL-Implementation des verwendeten Betriebssystem und/oder Treiber nicht richtig funktioniert. Wenn sie ganz freundlich drauf sind nehmen sie sich des ganzen vielleicht irgendwann mal an und programmieren in einer zukünftigen Version einen Workaround, aber in regel heißt es dann wohl eher: "Bitte melden sie diesen Fehler beim Hersteller ihrer OpenGL-Implementation".
Ich bin nicht ganz sicher, wie deine Antwort gemeint ist.
Wenn du damit aussagen willst, dass ein Hersteller sich um solche Probleme nicht kümmern soll: Sicherlich hast du damit recht, allerdings ist vorher oft gar nicht erkennbar, ob dies nun ein Fall ist, der eine Nachforschung bedarf, oder eben nicht. Dies weiß man für gewöhnlich erst danach.
Zudem ergibt sich damit ein weiteres Problem: Auch wenn der Hersteller einen Bug im System vielleicht ahnt, ist dies nicht automatisch für den Benutzer nachvollziehbar. Die Anwender sehen die Fehler oft dort, wo dieser sie trifft, ungeachtet dessen, wo er wirklich seine Ursache hat. Kümmert sich dann der Entwickler nicht um das Problem, wird die Schuld schnell diesem zugeschoben, auch wenn er dafür gar nichts kann. Dann ist zwar der Supportaufwand niedrig, aber das geschrei wegen der Probleme groß. Dann ist der Ruf ruiniert.
Bezüglich Google kann ich zu deren Arbeitsweise nichts sagen. Allerdings wäre ich eher überrascht, wenn man dort bereits bei jedem Bugreport wüsste, wo die Ursache liegt
Dazu ist es auch noch ein Unity Engine Spiel. Da sollte die Portierung eigentlich nicht sonderlich problematisch sein. Die zusätzlich gesammelte Erfahrung kann man gleich als Starthilfe für eine Android Portierung anrechnen.
Overhaul Games hat es schließlich auch geschafft Baldur's Gate auf Linux zu portieren und die mussten die Engine selbst anpassen.
Da ich selbst Unity für ein größere Projekt verwende, kann ich dazu folgendes sagen: Unity ist verbuggt von oben bis unten.
Zwar macht Unity die Portierungen wirklich leichter, aber dafür muss man sich nun mit Fehlern dort herumärgern. Bugfixe gibt es Teils gleich mit neuen Bugs im Bundle, sodass man (wenn man nicht als Kunde groß genug ist, um einen Sonderweg zu bekommen) abwägen muss, welcher Bug einen weniger stört :/
Unity hat viele Vorteile, aber es ist kein Allheilmittel.
Es ist schon etwas schwieriger, weil Tools fehlen, das KnowHow & die Erfahrung mit Linux fehlt. Das war deren erste Arbeit mit Linux, und Unity-Support für Linux war zu dem Zeitpunkt auch noch nicht so toll. Es braucht schon etwas mehr als nur einen Klick in Unity und wooops habe ich meinen Linuxbuild. So einfach ist es nicht.
Aber das ändert sich jetzt so langsam alles. Tools sind langsam da. Unity 5 für Linux kommt demnächst. Die Anzahl der Entwickler mit Erfahrungen in Spieleprogrammierung für Linux wächst.
Es wird besser, nur es braucht halt seine Zeit.
Ein Zitat eines Obsidian-Founders auf Reddit:
I'm one of the founders at Obsidian, and I definitely don't regret us supporting Linux on PoE. I'm admittedly biased as a Linux fanboy myself though.
We signed up to do it during our Kickstarter campaign as a stretch goal. I think [PoE's lead producer] Brandon's feeling was more from the trials and tribulations of setting it all up and problems we ran into during development. For example, it was harder to develop in Linux because Unity didn't support the tools at the time. Debugging was painful, but ultimately, we got it done, learned a bunch from the process, and now Linux is now fully supported in Unity.
FWIIW, we don't have any plans to not continue developing on Linux!
Von schmidicom am Di, 1. September 2015 um 13:44 #
Das die Erfahrung noch nicht da ist verstehe ich aber meinen ersten Programmiererlebnissen zufolge ist es unter Linux sehr viel einfacher herauszufinden wie etwas gemacht werden muss damit es funktioniert als unter Windows. Ob das auch auf Großprojekte zutrifft weiß ich nicht.
Irgendwie kann ich mir nicht wirklich vorstellen dass das Programmieren unter/für Linux so viel schwerer sein soll als unter/für Windows, zumindest nicht wenn der Wille dafür auch wirklich vorhanden ist.
Es steht ja auch da, dass das Programmieren einfach war. Nur der Support war aufwendig.
Support muss man eigentlich nur aufwenden wenn der Code fehlerhaft ist, also war die Portierung für sie entweder doch nicht so einfach wie behauptet oder sie haben sich dabei einfach nicht wirklich viel mühe gegeben. Und um genau diesen Widerspruch ging es mir in meinem Kommentar.
"Support muss man eigentlich nur aufwenden wenn der Code fehlerhaft ist"
Es gibt viele Gründe, warum sich Spieler an einen Hersteller wenden, dabei muss die Ursache keineswegs ein Fehler im Spiel selbst sein.
Wenn ein User an seinem System rumbastelt (was bei Linux ja nun mehr als wahrscheinlich ist), und dabei Fehler verursacht, dann können dabei Probleme entstehen, die mit dem Spiel nichts direkt zu tun haben, aber dort dann wiederum zu Fehlern führen. Solche Fehler zu finden kostet die Hersteller viel Zeit, und erzeugt umso mehr Frust, umso weniger sie mit dem Spiel selbst zu tun haben.
Da Linux eine extrem heterogene Umgebung ist, ist die Wahrscheinlichkeit für Probleme durch das Zusammenspiel von Komponenten entstehen, sehr hoch.
Zumal einige User eben auch dazu neigen, Änderungen am Basissystem durchzuführen, deren Konsequenzen sie nicht überblicken können. Bei Linux ist so etwas weit leichter und häufiger als bei Windows zu finden.
Dazu kommen teils noch eher maue kommerzielle Treiber bei Linux, welche die Sache auch nicht leichter machen.
Mag sein, wie Du es beschreibst.
Nur wie passt das mit der noch höheren Supportquote von MacOSX zusammen, die im Artikel erwähnt wird? Weil das läuft auf
- homogener Hardware
als
- homogene Software
Natürlich könnte man (da es auch ein *unix* ist) dort (in Grenzen) auch Änderungen an der Basiskonfiguration vornehmen, aber welcher Apple-User macht das schon?
Die Probleme mit OSX liegen wahrscheinlich daran, dass die Mehrheit der Mac-Benutzer "nur" einen Intel-Grafikchip verbaut hat (Über 95% der Macs sind Notebooks) und das bei Windows-Spielern eher selten der Fall ist.
Und so heterogen wie es immer dargestellt wird, ist die Mac-Landschaft auch wieder nicht.
Auf Grund des hohen Preises, sind Macs im Durchschnitt länger im Einsatz als ihre Windows-Pendants. Dazu kommt, dass Apple die Angewohnheit hat die Notebooks jedes Jahr mit CPU -und Chipsatz-Updates zu versehen.
Vom MacBook Air gab es seit 2011 vier Versionen und mit ziemlicher Sicherheit kommt dieses Jahr noch eine dazu:
2011 - Sandybridge-CPU mit HD3000-GPU (Max. OpenGL 3.3)
2012 - Ivybridge-CPU mit HD4000-GPU (Max. OpenGL 4.0)
2013 - Haswell-CPU mit HD5000-GPU (Max. OpenGL 4.3)
2014 - Broadwell-CPU mit Iris Pro-GPU (OpenGL 4.4)
2015(?) - Skylake-CPU mit Iris Graphics 5xx
Wenn die Entwickler jetzt ein Windows-Spiel portieren, dass massiv Gebrauch von DirectX11-Features macht, müssen sie entweder auf diese Features verzichten oder den Anwendern Einschränkungen bezüglich der Hardware aufzwingen (z.B. nur ab Intel HD5000).
Da viele Mac-Anwender auf Grund des identischen Äußeren gar nicht wissen, welche Hardware jetzt explizit verbaut ist, kaufen sie vielleicht ein Spiel um dann zu merken, dass ihre Hardware zu alt ist (Weil sie z.B. ein 2013er MacBook Air haben).
Was macht man dann? Man wendet sich an den Support.
"Wenn die Entwickler jetzt ein Windows-Spiel portieren, dass massiv Gebrauch von DirectX11-Features macht, müssen sie entweder auf diese Features verzichten oder den Anwendern Einschränkungen bezüglich der Hardware aufzwingen (z.B. nur ab Intel HD5000)."
Das Problem ist doch genauso unter Windows vorhanden. Da haben auch nicht alle Leute den gleichen Prozessor.
Unter Windows ist es auch eher üblich, dass man als Spieler weiß, welche Hardware verbaut ist. Zudem ist der Anteil der Spieler mit Notebooks deutlich niedriger als unter OSX.
Dazu kommen unter OSX noch Sachen wie die Retina-Displays, die in der Windowswelt bisher kaum vorkommen.
Eigentlich ist es eher umgekehrt. Nachdem man wohl kaum noch ein Android-Handy oberhalb der Einstiegsklasse ohne Display feiner als Retina verkaufen kann, gibt es bei Windows-Notebooks gefühlt entweder nur noch in super billig mit veralteter Auflösungen (das gibt es von Apple erst gar nicht) oder es muss besser als Retina sein, sobald man auch nur in die Nähe der Preisregion von Apple-Geräten kommt.
Gerade mal bei 'nem Anbieter die Notebookseite aufgerufen. Zu den Top-Sellern gehören (laut deren Aussage) das MSI GE62-2QFUi716H11 mit 3.840 x 2.160 Pixeln auf 15,6" und das Asus UX305FA-FB033H mit 3200 x 1800 auf 13,3" ... usw... und noch mehr oberhalb der Retina-Klasse.
Ne, das ist nichts ungewöhnliches mehr. Den Stein hat Apple ins Rollen gebracht und die Anbieter sind - sinnvoll oder nicht - auf den Zug aufgesprungen. Das ist auch in der Windows-Welt nichts ungewöhnliches mehr.
Allerdings dürfte die Bildschirmauflösung wohl bei Spielen, im Gegensatz zu so Dingen wie dem alten Windows XP-Desktop mit seiner festen Pixelausrichtung, sowieso kaum Supportanfragen auslösen. Da ist es doch schon immer üblich, die Spieleauflösung von der realen physischen Auflösung zu entkoppeln.
Treiberprobleme unter Linux bei Spielen treten in der Regel wegen zwei Dingen auf:
Ich kenne eigentlich keinen Spielehersteller unter Linux, der jemals ein Problem mit dem proprietären Nvidia-Treiber hatte.
Neben diesen beiden Problemen gibt üblicherweise nur dann Probleme, wenn ein Anwender das Spiel unbedingt auf einer nicht offiziell unterstützten Distribution spielen will.
Eine solche Haltung seitens Spielentwickler ist zwar nett aber wohl kaum praktikabel.
Nur so als Beispiel: Ich glaube kaum das es Google groß interessieren würde wenn in deren Chrome das WebGL nicht das macht was es soll nur weil die OpenGL-Implementation des verwendeten Betriebssystem und/oder Treiber nicht richtig funktioniert. Wenn sie ganz freundlich drauf sind nehmen sie sich des ganzen vielleicht irgendwann mal an und programmieren in einer zukünftigen Version einen Workaround, aber in regel heißt es dann wohl eher: "Bitte melden sie diesen Fehler beim Hersteller ihrer OpenGL-Implementation".
Ich bin nicht ganz sicher, wie deine Antwort gemeint ist.
Wenn du damit aussagen willst, dass ein Hersteller sich um solche Probleme nicht kümmern soll: Sicherlich hast du damit recht, allerdings ist vorher oft gar nicht erkennbar, ob dies nun ein Fall ist, der eine Nachforschung bedarf, oder eben nicht. Dies weiß man für gewöhnlich erst danach.
Zudem ergibt sich damit ein weiteres Problem: Auch wenn der Hersteller einen Bug im System vielleicht ahnt, ist dies nicht automatisch für den Benutzer nachvollziehbar. Die Anwender sehen die Fehler oft dort, wo dieser sie trifft, ungeachtet dessen, wo er wirklich seine Ursache hat. Kümmert sich dann der Entwickler nicht um das Problem, wird die Schuld schnell diesem zugeschoben, auch wenn er dafür gar nichts kann. Dann ist zwar der Supportaufwand niedrig, aber das geschrei wegen der Probleme groß. Dann ist der Ruf ruiniert.
Bezüglich Google kann ich zu deren Arbeitsweise nichts sagen. Allerdings wäre ich eher überrascht, wenn man dort bereits bei jedem Bugreport wüsste, wo die Ursache liegt
Dazu ist es auch noch ein Unity Engine Spiel. Da sollte die Portierung eigentlich nicht sonderlich problematisch sein. Die zusätzlich gesammelte Erfahrung kann man gleich als Starthilfe für eine Android Portierung anrechnen.
Overhaul Games hat es schließlich auch geschafft Baldur's Gate auf Linux zu portieren und die mussten die Engine selbst anpassen.
Da ich selbst Unity für ein größere Projekt verwende, kann ich dazu folgendes sagen: Unity ist verbuggt von oben bis unten.
Zwar macht Unity die Portierungen wirklich leichter, aber dafür muss man sich nun mit Fehlern dort herumärgern. Bugfixe gibt es Teils gleich mit neuen Bugs im Bundle, sodass man (wenn man nicht als Kunde groß genug ist, um einen Sonderweg zu bekommen) abwägen muss, welcher Bug einen weniger stört :/
Unity hat viele Vorteile, aber es ist kein Allheilmittel.
Es ist schon etwas schwieriger, weil Tools fehlen, das KnowHow & die Erfahrung mit Linux fehlt. Das war deren erste Arbeit mit Linux, und Unity-Support für Linux war zu dem Zeitpunkt auch noch nicht so toll. Es braucht schon etwas mehr als nur einen Klick in Unity und wooops habe ich meinen Linuxbuild. So einfach ist es nicht.
Aber das ändert sich jetzt so langsam alles. Tools sind langsam da. Unity 5 für Linux kommt demnächst. Die Anzahl der Entwickler mit Erfahrungen in Spieleprogrammierung für Linux wächst.
Es wird besser, nur es braucht halt seine Zeit.
Ein Zitat eines Obsidian-Founders auf Reddit:
Quelle: Reddit.comHier noch das Video dazu: PAX 2015 - Obsidian
Stellen mit Linuxbezug bei 33m & 55m.
Das die Erfahrung noch nicht da ist verstehe ich aber meinen ersten Programmiererlebnissen zufolge ist es unter Linux sehr viel einfacher herauszufinden wie etwas gemacht werden muss damit es funktioniert als unter Windows. Ob das auch auf Großprojekte zutrifft weiß ich nicht.