ZFX + Developia

Z-Developer hat geschrieben: Eine Portierung darf meiner Meinung nach kein Abfallprodukt sein! Dann lieber keine Portierung! Denn mit einer schlechten Portierung macht man sich keine Freunde.

Ich denke kaum, wenn die Enwickler eine Linux-Version für den Privatgebrauch haben, dass diese eine soo schlechte Qualität haben wird.

Weißt du antisteo, ich glaube niemand ist so besessen von Linux, dass er in seiner Freizeit das Spiel an dem er den ganzen Tag arbeitet nach Linux portiert. Der Mehrwert für den Entwickler ist gleich 0, da er auch einfach die Zielplattform verwenden könnte, und die Idee bei Freizeit ist ja mal was anderes zu tun als bei der Arbeit. Ganz abgesehen davon dass nicht klar ist ob der Rechteinhaber (Arbeitgeber) das erlauben würde. Es mag vereinzelt Software-Projekte geben, bei denen der Mehrwert für eine Einzelperson es zu portieren größer ist als der Aufwand, bei Spielen ist dies jedoch sicher nicht der Fall. Vielleicht solltest du dich von der romantischen Vorstellung verabschieden, alle professionellen Entwickler seien leet haX0r die ausschließlich Linux verwenden.

Alexander Kornrumpf hat geschrieben:Weißt du antisteo, ich glaube niemand ist so besessen von Linux, dass er in seiner Freizeit das Spiel an dem er den ganzen Tag arbeitet nach Linux portiert. Der Mehrwert für den Entwickler ist gleich 0, da er auch einfach die Zielplattform verwenden könnte, und die Idee bei Freizeit ist ja mal was anderes zu tun als bei der Arbeit. Ganz abgesehen davon dass nicht klar ist ob der Rechteinhaber (Arbeitgeber) das erlauben würde. Es mag vereinzelt Software-Projekte geben, bei denen der Mehrwert für eine Einzelperson es zu portieren größer ist als der Aufwand, bei Spielen ist dies jedoch sicher nicht der Fall. Vielleicht solltest du dich von der romantischen Vorstellung verabschieden, alle professionellen Entwickler seien leet haX0r die ausschließlich Linux verwenden.

Sehe ich genau so.

@rüp:
Ok, da habe ich wohl etwas falsch verstanden. Vielen Dank für die Information!

@Lynxeye
Da hast du natürlich Recht.

Alexander Kornrumpf hat geschrieben:Weißt du antisteo, ich glaube niemand ist so besessen von Linux, dass er in seiner Freizeit das Spiel an dem er den ganzen Tag arbeitet nach Linux portiert. Der Mehrwert für den Entwickler ist gleich 0, da er auch einfach die Zielplattform verwenden könnte, und die Idee bei Freizeit ist ja mal was anderes zu tun als bei der Arbeit. Ganz abgesehen davon dass nicht klar ist ob der Rechteinhaber (Arbeitgeber) das erlauben würde. Es mag vereinzelt Software-Projekte geben, bei denen der Mehrwert für eine Einzelperson es zu portieren größer ist als der Aufwand, bei Spielen ist dies jedoch sicher nicht der Fall. Vielleicht solltest du dich von der romantischen Vorstellung verabschieden, alle professionellen Entwickler seien leet haX0r die ausschließlich Linux verwenden.

Das verstehst du falsch.
Ich meine nicht, dass der Entwickler voll der Fenster-Fanatiker ist, sondern eher der professionelle Programmierer, der aufgrund der optimaleren Umgebung auf Linux arbeitet und nur für das Release dann den Crosscompile wagt. Die Rede ist hier nicht vom "Mehrwert", sondern dass ein Linuxer sich wohl kaum zum Entwickeln auf Windows begeben würde (Weil Windows eher für Spieler gedacht ist).
So war es z.B. bei meinem Projekt: Es gab die Diskussion, dass einige Windowser nicht wollten, dass das Spiel (welches schon portiert war), auch für Linux gibt. Jedoch ließ sich die Forderung nicht durchsetzen, da der Anteil an Linux-Entwicklern zu dem Zeitpunkt bei 100% lag. (und nur für die Spieler ein Windows-Port erstellt wurde.)

--> Perspektivenwechsel - schau mal über deinen (M$-)Tellerrand

antisteo hat geschrieben: Das verstehst du falsch.
Ich meine nicht, dass der Entwickler voll der Fenster-Fanatiker ist, sondern eher der professionelle Programmierer, der aufgrund der optimaleren Umgebung auf Linux arbeitet und nur für das Release dann den Crosscompile wagt.

Komm mal bitte aus deiner eigenen kleinen Welt raus. Niemand der ernsthaft verkaufsfähige AAA Spiele entwickelt tut das auf Linux. Dafür bietet Windows in der Richtung einfach zu gute Voraussetzungen. Ich bin auch privat vollkommen überzeugter Tuxer und arbeite da auch gern an der Codebase mit, wenn ich Zeit habe. Wenn ich aber morgens aus der Tür gehe und auf Arbeit ankomme, setze ich mich auch an eine Windowsmachine. Wenn man Software für Windowsumgebungen entwickelt, tut man dies auch auf Windowsmachinen; da macht niemand einen Crosscompile. Professionalität bedeutet die besten Werkzeuge für ein gegebenes Problem zu wählen und das ist bei Spielen nun mal (leider) eine Windowsumgebung.

Also ich bin mit dem ganzen C++ und VisualStudio-Zeugs nie klargekommen, als wir es im Studium nutzen mussten.
Da schreibt sich doch eine Makefile 10x einfacher als so ein hin- und hergeklicke und Pfade einstelle, dann noch diese absoluten Pfade (auch blöd bei Eclipse), die das ganze Projekt Teamwork-unfähig machen, keine Möglichkeit, den Build eines VisualStudio-Projekts auf einen Server auszulagern, um nightly builds zu machen, sprich: Ich sehe nicht, wo du meinst, bessere Tools unter Win zu haben.

Schluss mit dem Schwachsinn, antisteo. Es geht nicht drum welche Plattform bessere Entwicklungswerkzeuge hat. Es geht darum, fuer welche Plattform es genug zahlende Kunden gibt damit sich die Entwicklung lohnt.

Kommst du dir nicht ein klein bisschen laecherlich vor wenn du in einem Thread ueber die Vermarktung von Computerspielen ueber irgendwelche Dialoge mit absoluten Pfaden herziehst?

antisteo hat geschrieben:

Z-Developer hat geschrieben: Eine Portierung darf meiner Meinung nach kein Abfallprodukt sein! Dann lieber keine Portierung! Denn mit einer schlechten Portierung macht man sich keine Freunde.

Ich denke kaum, wenn die Enwickler eine Linux-Version für den Privatgebrauch haben, dass diese eine soo schlechte Qualität haben wird.

Ich vermute die meisten Konsolenentwickler entwickeln unter Windows und nicht auf den Konsolen selbst, dennoch gibt es genugend negative Beispiele, wo der Windows-Port selbst wie ein Abfallprodukt wirkt.

@Windows-Werkzeuge: Das Du deine eigene Unfaehigkeit einfache Tools zu benutzen und deine Unwissenheit ueber die Moeglichkeiten von Windows hier so ausweitest ist natuerlich deine Sache, aber es unterstuetzt nur wenig deinen Satz "--> Perspektivenwechsel - schau mal über deinen (M$-)Tellerrand".

Vielleicht waere es sinnvoller, wie Aramis schon gesagt hat, sich wieder auf das eigentliche Thema zu konzentrieren, statt krampfhaft zu versuchen einen unreifen Flamewar zu fuehren.

Mal von den unterschiedlichen Standpunkten abgesehen, muss denn dieser rauhe Ton sein?

Seraph hat geschrieben:@Windows-Werkzeuge: Das Du deine eigene Unfaehigkeit einfache Tools zu benutzen und deine Unwissenheit ueber die Moeglichkeiten von Windows hier so ausweitest ist natuerlich deine Sache, aber es unterstuetzt nur wenig deinen Satz "--> Perspektivenwechsel - schau mal über deinen (M$-)Tellerrand".

Ich kenne die andere Seite des Tellerrands, ich weiß wie es funktioniert und finde es trotzdem zu umständlich. Grausam, dass man so was immer mit GUI machen muss und es keine Konsolenbefehle dafür gibt. Aber das ist Grund für viele weitere Flamewars, deshalb lasse ich es so im Raum stehen.

Tiles hat geschrieben:Mal von den unterschiedlichen Standpunkten abgesehen, muss denn dieser rauhe Ton sein?

Nein,

deshalb back2topic:
Ich empfehle keinem, einen Linux-Port für irgendein Spiel zu machen, wenn er nicht selbst die Linux-Plattform über alles liebt. Es gibt so viele stiefmütterliche Ports und Linuxer sind anspruchsvoll, was Software angeht.

Beispiel wie man es falsch macht: Das UML-Tool MagicDraw:
- Installer sollte man unter Linux vermeiden, vor allem tabu sind GUIs im Installer.
- Der Installer knallt sämtliche Binaries in das Home-Verzeichnis
- Der Installer legt keinen Konsolenbefehl und keinen Menüpunkt im OpenDesktop an

Jetzt das Gegenbeispiel, wie man es richtig macht:
- Man sollte sich mit den Paketsystemen DEB, RPM oder EMERGE auseinandersetzen und seine Software als ein solches Paket veröffentlichen
- Für das Paket sollte man einen Spiegel mit Updates anbieten. Ganz schlecht kommt eine selbstimplementierte Update-Funktion an
- Einstellungen sollten generell im Ordner "~/.Programmname/" angelegt werden
- Die Einzelfunktionen des Programms sollten auch als Konsolenbefehle angesprochen werden können (bei Spielen z.B. welches Spiel gestartet wird) - ganz deluxe ist natürlich ein Auto-Vervollständigungsmodul

Wie man sieht - eine Menge zu beachten. Und mit einer guten Wine-Kompatibilität macht man sich definitiv mehr Freunde als mit einem schlechten Port.

“when you’re a hammer everything looks like a nail.”

Kommt mir bekannt vor.....
Wurde doch letztens im ChaosRadio-Stream über C++ zitiert!! Finde ich sehr passend... :)

Alexander Kornrumpf hat geschrieben:Es mag vereinzelt Software-Projekte geben, bei denen der Mehrwert für eine Einzelperson es zu portieren größer ist als der Aufwand, bei Spielen ist dies jedoch sicher nicht der Fall.

Ich weiß nicht, was du falsch machst, aber bei den Libs und Tools, die ich verwende ist der Portierungsaufwand fast 0.
Das würde wiederum implizieren, dass eine Linux-Portierung sich negativ auf das Projekt auswirkt. Erklär mir das doch mal.


Edit: Ich weiß natürlich, dass du das nich damit meinst,
jedoch hängt der Aufwand oder die Möglichkeit des Portierens sehr stark von den verwendeten Tools ab (wollte ich damit sagen) - demzufolge gehört es mmn zum guten Programmierstil, diese zu verwenden. Einfach der Möglichkeit wegen.

antisteo hat geschrieben:Es gibt so viele stiefmütterliche Ports und Linuxer sind anspruchsvoll, was Software angeht.

Ach deswegen gibt es so anspruchsvolle Software wie GCC, der jeden Scheiss zusammenlinkt oder 15-seitige Fehlermeldungen produziert...

- Installer sollte man unter Linux vermeiden, vor allem tabu sind GUIs im Installer.

Ah, so wie die Installer für die ganzen (kommerziellen) Spiele :roll:

- Der Installer knallt sämtliche Binaries in das Home-Verzeichnis
- Der Installer legt keinen Konsolenbefehl und keinen Menüpunkt im OpenDesktop an

Das ist in der Tat blöd.

Jetzt das Gegenbeispiel, wie man es richtig macht:
- Man sollte sich mit den Paketsystemen DEB, RPM oder EMERGE auseinandersetzen und seine Software als ein solches Paket veröffentlichen

Komm mal in der Realität an. Die viele kommerzielle Software für Linux gibt es meist als RPM (da Red Hat zertifiziert) oder eher als .tar.gz. Als Hersteller hab ich überhaupt keine Lust, mich mit 10+ Paketsystemen auseinanderzusetzen - und das trifft sowohl für kommerzielle als OSS-Software. Ltzteres kommt meist nur als Source, da darf sich jede Distribution dann selber ein Paket bauen, und schon trifft dein Punkt nicht mehr zu.

- Für das Paket sollte man einen Spiegel mit Updates anbieten. Ganz schlecht kommt eine selbstimplementierte Update-Funktion an

Also ich find das super, dass sich meine Firefox-Plugins selber aktualisieren, falls nötig...

- Die Einzelfunktionen des Programms sollten auch als Konsolenbefehle angesprochen werden können (bei Spielen z.B. welches Spiel gestartet wird)

Wie kopier ich von der Shell was von Konqueror oder Nautilus in die Zwischenablage?

Wie man sieht - eine Menge zu beachten. Und mit einer guten Wine-Kompatibilität macht man sich definitiv mehr Freunde als mit einem schlechten Port.

Ansichtssache, viele Leute sind auch über einen schlechten Port froh.


Und zum Schluss der Disclaimer: ich mag mein Debian viel mehr als jedes Windows :ugeek:

antisteo hat geschrieben:Edit: Ich weiß natürlich, dass du das nich damit meinst,
jedoch hängt der Aufwand oder die Möglichkeit des Portierens sehr stark von den verwendeten Tools ab (wollte ich damit sagen) - demzufolge gehört es mmn zum guten Programmierstil, diese zu verwenden. Einfach der Möglichkeit wegen.

Auch das ist nicht so einfach: Wenn es "Die beste Lösung" für ein bestimmtes Problem nur für Windows gibt, was machst du dann? Das hat weniger was mit Programmierstil zu tun, als mit Aufwand/Nutzen.

Ob es mal eine Diskussion geben wird, bei der Microsoft und Linux erwähnt werden und sich die Leute nicht im lauten Ton Unfähigkeit vorwerfen werden? Ich glaube kaum *seufz* ...
MAl etwas ketzerisches: Windows 7 ist vom Design sicherer als Linux, da es mittlerweile einen großen Haufen Sciherheits-Features mitbringt. Nun dürft ihr mich töten. Ich entwickle übrigens unter Linux und Windows.

Gruß Kimmi

antisteo hat geschrieben:

Alexander Kornrumpf hat geschrieben:Es mag vereinzelt Software-Projekte geben, bei denen der Mehrwert für eine Einzelperson es zu portieren größer ist als der Aufwand, bei Spielen ist dies jedoch sicher nicht der Fall.

Ich weiß nicht, was du falsch machst, aber bei den Libs und Tools, die ich verwende ist der Portierungsaufwand fast 0.
Das würde wiederum implizieren, dass eine Linux-Portierung sich negativ auf das Projekt auswirkt. Erklär mir das doch mal.

*cry*

Lies bitte noch mal ganz sorgfältig was du zitiert hast. Ich wollte es erst fetten um dir das Verständnis zu erleichtern, aber dann hätte ich den ganzen Satz fetten müssen. Es mag libs und tools geben, auf die zutrifft was du sagst und es mag sein dass du persönlich nur solche verwendest. Auf Spiele trifft dies jedoch nicht zu. Ein Projekt von der Größe eines AAA Spiels kompilierst du nicht mal eben unter Linux mit dem gcc und das war dann deine Portierung.

Das soll nicht bedeuten dass man Spiele nicht so entwickeln könnte, dass o.g. möglich wäre, sondern nur dass es zusätzlichen Aufwand* bedeutet, der sich mangels passender Vermarktungsmöglichkeiten unter Linux nicht lohnt. Deshalb gehen deine Beiträge voll am Thema vorbei (was nach der Threadteilung nun auch egal ist). Ein sinnvoller Beitrag zum Thema wäre eine Beschreibung wie in der Linux-Zielgruppe den Aufwand finanziell wieder reinholt, du dagegen leugnest dass es überhaupt Aufwand ist.

Edit: Ich weiß natürlich, dass du das nich damit meinst,
jedoch hängt der Aufwand oder die Möglichkeit des Portierens sehr stark von den verwendeten Tools ab (wollte ich damit sagen) - demzufolge gehört es mmn zum guten Programmierstil, diese zu verwenden. Einfach der Möglichkeit wegen.

Also ich habe mich schon oft genug geärgert dass es eine bestimmte lib mit funktionen die ich nützlich gefunden hätte nicht nativ für Windows gibt und sich auch nicht ihne weiteres kompilieren lässt. Also was verlangst du da gerade? Die Windows-Entwickler sollen ihre Programme mal schön portabel halten, damit die Linuxer diese nutzen können, aber wenn ein Windows-Entwicker Linux libraries nutzen will soll er masl schön das Betriebssystem wechseln? Seltsame Doppelmoral. Und bevor du es erwähnst, cygwin qualifiziert sich wohl genausowenig als native Portierung wie wine. Also jetzt bitte kein "mit cygwin gehts doch".

Alexander Kornrumpf hat geschrieben: Also ich habe mich schon oft genug geärgert dass es eine bestimmte lib mit funktionen die ich nützlich gefunden hätte nicht nativ für Windows gibt und sich auch nicht ihne weiteres kompilieren lässt. Also was verlangst du da gerade? Die Windows-Entwickler sollen ihre Programme mal schön portabel halten, damit die Linuxer diese nutzen können, aber wenn ein Windows-Entwicker Linux libraries nutzen will soll er masl schön das Betriebssystem wechseln? Seltsame Doppelmoral. Und bevor du es erwähnst, cygwin qualifiziert sich wohl genausowenig als native Portierung wie wine. Also jetzt bitte kein "mit cygwin gehts doch".

MinGW libs tuns auch.

Ich lehne sowohl die WinAPI als auch die Linux-Only-Bibliotheken (X11) ab. Und wenn man diese doch nutzen müsste (weil sie eben auf unterster Ebene dann doch benutzt werden müssen), dann bin ich quasi gezwungen, verzweigten Code zu schreiben (#ifdef unix). Ist mir aber bis jetzt erspart geblieben. (ich nutze das LCL Framework, das nativ für Win, MAC und Linux implementiert ist und so ziemlich alles bietet, was ich bis jetzt gebraucht habe)

Welche Beispiele an Libs gibt es denn, die noch nicht portiert wurden?

DirectX9 & DirectX10 & DirectX11 zum Beispiel: wurden nicht portiert. Zwar gibt es OpenGL, aber man kriegt bei DirectX auch einige gute Dinge mitgeliefert ( wobei Remote-Betrieb leider nicht dazu gehört ).

Gruß Kimmi

antisteo hat geschrieben: MinGW libs tuns auch.

Ernstgemeinte Frage: kann man die auch mit dem Microsoft-Complier bzw. Visual Studio verwenden? Wenn es wirklich statische libs sind und keine dynamischen kann ich mir die Frage insofern selbst beantworten, als dass gcc libs meines Wissens nicht kompatibel zu msvc sind. Allerdings könnte es ja sein dass man MingW an sich auch mit msvc kompilieren kann. Sollte das wiederum nicht gehen, wäre mingw auch nicht wirklich portabel.

Als ich vor geraumer Zeit mal MingW verwenden wollte war das alles noch sehr stark auf den gcc zentriert.

Evtl. passt da auch meine Frage dazu, die mich schon seit Langem begleitet: kann man DirectX mit dem GCC benutzen? Oder kann der GCC allgemein Libs von MSVC benutzen? Der GCC hat nämlich aktuell die Nase vorn, was die Performance des generierten Codes angeht. Ich würde gern mal die Splitterwelten damit durchkompilieren, wenn ich dadurch zehn zwanzig Prozent Tempo geschenkt bekomme.

Früher (TM) war es meines wissens so dass die statischen libs die MS mit dem SDK ausgeliefert hat nicht gcc kompatibel waren. Man konnte allerdings ohne diese statischen libs leben, da sie nur für komfortablen iIport der dlls gedacht waren. Das eigentliche DirectX (also die dlls) war kompatibel

D.h. ich müsste den DLL-Import von Hand schreiben, dann geht's? Hm. Für Direct3D müsste das reichen, da gibt es ja nur ein paar Funktionen und der Rest geht über Interfaces, die man von diesen paar Funktionen zurückbekommt. Bleibt noch NVidia PhysX, fmodex, Qt und tbb - für die müsste es verschieden einfach sein, Linkerlibs für den GCC zu kriegen.

Alexander Kornrumpf hat geschrieben:

antisteo hat geschrieben: MinGW libs tuns auch.

Ernstgemeinte Frage: kann man die auch mit dem Microsoft-Complier bzw. Visual Studio verwenden? Wenn es wirklich statische libs sind und keine dynamischen kann ich mir die Frage insofern selbst beantworten, als dass gcc libs meines Wissens nicht kompatibel zu msvc sind. Allerdings könnte es ja sein dass man MingW an sich auch mit msvc kompilieren kann. Sollte das wiederum nicht gehen, wäre mingw auch nicht wirklich portabel.

Als ich vor geraumer Zeit mal MingW verwenden wollte war das alles noch sehr stark auf den gcc zentriert.

Die Sourcecodes sind alle offen und beide, GCC und der VS C++-Compiler setzen den C++ Standard um (VC ein bisschen mehr, aber das soll uns jetzt nicht stören).

Ich weiß, dass man mit dem GCC VS-Libs linken kann und dass MS Office sogar das ODT-Format unterstützt. Demzufolge besteht schon eine Chance, dass Microsoft auch GCC-Libs bzw. Objektdateien kennt.

MinGW bietet auch andere Tools, die z.B. eine statische Lib in eine dynamische umrechnen (http://wyw.dcweb.cn/stdcall.htm).

Schrompf hat geschrieben:Der GCC hat nämlich aktuell die Nase vorn, was die Performance des generierten Codes angeht. Ich würde gern mal die Splitterwelten damit durchkompilieren, wenn ich dadurch zehn zwanzig Prozent Tempo geschenkt bekomme.

Sauce plox

Deswegen lohnt sich mener Meinung nach immer mal, den Code schön portabel zu halten. Dann kann man auch mal vergleichen, was wo schneller ist und warum. Aber ich bin eh ein Portier-Fetischist :).

Gruß Kimmi

Krishty hat geschrieben:Sauce plox

Den hab ich gegoogelt, aber ich versteh ihn trotzdem nicht.

@Kimmi: ich dachte, ich hätte portabel programmiert, bis mir vor ein paar Tagen erst jemand auf sppro erzählt hat, dass meine Iteratorloops eine VC-eigene Erweiterung sind... :-/ So kann's gehen.

Schrompf hat geschrieben:

Krishty hat geschrieben:Sauce plox

Den hab ich gegoogelt, aber ich versteh ihn trotzdem nicht.

Quelle, bitte ;) Ich glaube nämlich nicht, dass sich VCpp/GCC/ICC mit PGO mehr als fünf Prozent tun.

@Schrompf: ich mach öfter mal den gcc-test unter Linux. Der zeigt einem schnell, was man falsch verstanden hat. Und ich hab 4 Jahre lang eine mittelgroße Codebasis portiert. Das schärft die Sinne ( vor allem, weil die STL, nein kein Witz, mir verboten wurde ).

Gruß Kimmi

Krishty hat geschrieben:Quelle, bitte ;) Ich glaube nämlich nicht, dass sich VCpp/GCC/ICC mit PGO mehr als fünf Prozent tun.

Ich habe es nie persönlich nachgemessen - das war nur eine gedankliche Notiz, die aus vielen Diskussionen im Netz entstanden war, dass GCC anscheinend in den aktuellen Versionen besseren Code produziert als VC++. Daher der Gedanke, bei Gelegenheit mal ein für mich relevantes Projekt mit dem GCC zu übersetzen und das Ergebnis zu prüfen. Und daher dann auch die Frage, ob man VC-Libs mit dem GCC linken kann - ein paar der von uns verwendeten Libs kommen nur mit VC-Libs daher.

Ich habe jetzt mal schnell gegoogelt, aber nur weitere Diskussionen oder offensichtliche Fehlexperimente (wie z.B. dieser Adobe Performance Test) gefunden. Ich weiß also nicht, wieviel Unterschied da tatsächlich besteht.