Ist zwar traurig, dass Carmack die Entwicklung der Spiele unter Linux zurückzieht, aber dennoch bin ich dankbar für die Offenheit die er bei Id weiter pflegt. Ich meine es ist ja auch irgendwo verständlich, dass für ein Unternehmen die Portierung zu Linux irgendwann unwirtschaftlich wird. Meine einzige Hoffnung ist, dass er OpenGL treu bleibt. Und die endlich in die Gänge kommende Entwicklung von OpenGL bei der Khronos Group gibt da auf jeden Fall Hoffnung.
Von Erkenner der Personen am Mo, 16. August 2010 um 13:46 #
Auf dem Foto hat John Carmack aber schon nen ganz schönen Buckel. Kommt das vom täglichen Programmieren?
Außerdem hat er da eine offene Pepsiflasche stehen. So etwas würde ich nie machen, sondern immer den Deckel draufmachen. Denn man kann ja nie wissen, ob nichtmal ne Wespe in die Flasche fliegt.
In einer solchen Sitzposition hält ein Mensch auf seinem Arbeitsplatz wohl kaum lange durch. Wahrscheinlich saß er für das Foto am "falschen" Rechner eines Kollegen, da sein Arbeitsplatz vielleicht so chaotisch unaufgeräumt war (nur eine Vermutung von mir). Die Fotoszene ist wohl gestellt, dafür spricht auch das gerade geöffnete, aber immer noch randvolle Cola-Fläschchen. Und natürlich der Buckel.
Von The Roadrunner am Mo, 16. August 2010 um 18:06 #
Das ist ein ganz schoen altes Foto - genau dieses verwendet prolinux immer, wenn es um John geht; und jedes mal kommt es zur Diskussion ueber seine Sitzhaltung.
Sehe ich genau so! Hätte man sich vor 3-4 Jahren als Ubuntu hochkam auch 100% auf Wine konzentriert, würden heute viele Spiele auch unter Linux/Wine laufen. (Mit "laufen" meine ich schon "Platinum"-Rating bei winehq - nicht Frickelsilber). Aber nein! Es folgte diese sinnlose Diskussion, dass alles nativ, blablabla, laufen muss. Ich habe mich damals schon gefragt: WIESO? Darauf hatte auch keiner eine sinnvolle Antwort. Es ist diese dämliche "Überheblichkeit" (es ist defacto nur Dummheit) mancher open-source Leuten, die eine strikte Trennlinie zwischen Windows und Linux machen wollen. Vor allem, die erwarten ernsthaft (!), dass sich dann manche Spielefirmen (nicht unbedingt id, die sind insgesamt nett) sich dann die Mühe machen und das Ganze auf Linux portieren ?! WTF? Über Wine hätte vll eine sinnvolle Angleichung stattfinden können. Auch für den Enduser.
Kommentar bezieht sich auf folgendes Zitat: " Wie die Linux-Spieleseite »LinuxGames« berichtet, sei es laut Carmack schwer, die Vorteile einer Portierung für Linux zu finden. Demnach ergeben Projekte wie Wine mehr Sinn."
Allerdings ist das kein grundsätzliches, systembedingtes Problem sondern "nur" ein Problem der Implementierung das gelöst werden kann. WINE ist halt wirklich kein Emulator.
Dummerweiße ist das kein Problem, das leicht zu lösen ist, sondern Prinzipbedingt. Solche Probleme wird es am Ende wohl immer geben, 100%ig geht einfach nicht.
naja bin zwar kein spezialist, aber einige d3d bezogene sachen laufen auf wine auch wesentlich schneller als unter windows (ja das ist so), einige dinge aber eben auch wesentlich langsamer, so ergibt sich zusammen ein performance verlust. ich denke nicht dass man in wine einen großen aufwand betreibt zu optimieren, man ist froh, dass die scheisse überhaupt läuft und hat genug damit zu tun den rest der noch fehlt zu implementieren. ich denke aber es wäre durchaus möglich da einiges zu optimieren, was dann aber wohl das risiko hätte dass diese optimierungen plattformabhängig sind und das möchte man bei wine wohl auch nicht..
Auch wenn ich mir recht sicher bin, das dies nur ein Trollversuch von dir ist:
"Darauf hatte auch keiner eine sinnvolle Antwort. "
Das bezeifle ich, es gibt immerhin gute Gründe warum native Lösungen vorzuziehen sind.
An der Stelle möchte ich folgende Nennen, es gibt aber natürlich noch weitere:
1. Wine ist eine in vielen fällen nutzbare Lösung, jedoch weit ab vom perfekten. Praktisch jeder Wine-Release bringt regressions, etwas das sich auch kaum verhindenr lässt, ist doch auch Windows davon betroffen. Wine ist jedoch, auch durch die viele Arbeit die darin zu investieren ist, um mit der Windowswelt schritt zu halten, viel stärker davon betroffen. Praktisch jeder Commit in Wine bringt quasi zwei neue Funktionen, und zerstört eine alte.
2. Die Anwendungen laufen nativ zumeist deutlich schneller
3. Nur wenige Anwendungen und spiele laufne mit Wine gut. Die großen Namen wie World of Warcraft täuschen darüber hinweg, das die meisten Spiele nur mäßig, schlecht oder garnicht funktionieren. Dies ist auch kein Umstand, der leicht zu lösen ist, das Windowsgesamtsystem ist komplex, und schon kleine Abweichungen im Verhalten können ernsthafte Probleme in den Spielen hervorrufen. Dies ist auch in den Unterschieden von Linux und Windows begründet. Viele kleine und größere Unterschiede (Casesensitive Dateisysteme, netzwerkfähige GUI mit Layertechnik, starke Variationen von Systemlibversionen, Unterstützung für mehr als eine Prozessorfamilie usw.) machen es auch praktisch unmöglich Wine wirklich stabil zu bekommen.
Wine ist in Ordnung, als Hilfe ist es super, aber wirklich gut wird damit nie alles laufen. Die Anforderung, Windows in einem nicht-Windows System perfekt nachzubilden, ist einfach zu hoch, als das es wirklich möglich wäre.
Ein Angleichung, unter Bewahrung der Besonderheiten, ist schlicht nicht möglich. Es sind einfach Äpfel und Birnen. Das wird einfach nie das gleiche werden, auch nicht mit einer Zuckerglasur.
Nebenher: Wären die Spieel Open Source, würden User meist die Portierung durchführen. Alle spiele, deren Quellcode freigegeben wurden, sind kurz darauf als Multiplattformtitel verfügbar gewesen (Descent, die ID Spiele usw.)
Kein Trollversuch. Natürlich sind native Lösungen immer besser als Layer-Lösungen. Aber welche Firma bringt denn ernsthaft eine native Version raus für <3% potentielle Käufer? Sogar bei id war es zuerst ein Third-Party-Port auf Linux. Zu deinen Punkten 1-3: Klar, das sind die allgemeinen Probleme mit Wine. Aber dennoch sehe ich Wine als die Zukunft des (kommerziellen) Spielens unter Linux. War es vor 4 Jahren, wird es hws auch in 4 Jahren sein.
"Aber dennoch sehe ich Wine als die Zukunft des (kommerziellen) Spielens unter Linux. War es vor 4 Jahren, wird es hws auch in 4 Jahren sein."
Das sehe ich genauso. Ich nutze unter Linux mit Wine noch ein paar Windowsspiele, u.a. uralte Mahjongg-Spiele und das noch ältere Civilization II. Civ II läuft mittlerweile mit Wine ganz hervorragend, immer vorausgesetzt, man schaltet alles ab, was irgendwie mit "Sound" zusammenhängt. In diesem Zusammenhang sollte man auch nicht vergessen, dass es nicht immer möglich ist, alte native Linuxspiele auf aktuellen Linuxdistributionen zu spielen. Die Rückwärtskompatibilität ist mitunter katastrophal (vor allem bei Distros, die noch nie etwas von "compat"-Paketen gehört haben). Von daher bräuchte es fast schon ein "Line".
Von programmierer am Mo, 16. August 2010 um 15:42 #
Ich weiß nicht was ihr habt... ich programmiere seit etlichen Jahren unter Windows. Als ich versucht habe (bin immer noch dabei) auf Linux zu wechseln, fehlten mir sehr viele Tools. Alleine Visual Studio Ultimate ist rundum ein gelungenes Paket, dass nur sehr schwer zu ersetzen ist. A
Wenn man auf irgendwelche Anwendungen fixiert ist, die unter Windows laufen, tut man sich natürlich keinen Gefallen, erst recht nicht wenn diese Anwendungen von Microsoft kommen. Es gibt, gerade was Softwareentwicklung betrifft, eine breite Auswahl an Anwendungen unter Linux. Wenn nun nicht exakt die Anwendung, die man unter Windows genutzt hat, zufälligerweise auch unter Linux vorhanden ist, wird man gerade bei IDE's immer die ein oder andere Sache vermissen, einfach weil diese Anwendungen so umfangreich sind. Lässt man sich trotzdem darauf ein, wird man dafür früher oder spätere andere Dinge, die man bei der Windows Anwendung eben nicht hat, kennen und schätzen lernen. So ist es mit einer ganzen Menge Anwendungen.
Das Problem vieler Windows User ist doch, sie suchen unter Linux z.B. nicht nach Bildbearbeitungsprogrammen oder IDE's, sondern nach einer Alternative zu Visual Studio und Adobe PS. Wenn das Linux Pendant dann eine Sache nicht kann, die man unter Windows gewohnt ist, heißt es sofort, man könne mit dem Betriebssystem nicht arbeiten.
Naja, hast du dir mal das DirectX SDK angeschaut? Das ist unglaublich umfangreich, bringt viele Beispiele und eine umfassende Dokumentation mit - wo bekomme ich sowas für OpenGL?
Du vergleichst da wohl gerade Äpfel und Birnen. OpenGL ist nur eine Alternative zu Direct3D, nicht zu dem ganzen Paket DirectX. Du kannst höchsten die Kombination aus SDL und OpenGL sinnvoll mit DirectX vergleichen
Bitte bring nicht SDL ins Spiel. Damit kannst du dir nur selber ins Knie schießen.
Und wenn du es doch willst dann sage ich dir gleich SDL wird verlieren.
DirectX (damit meine ich das Gesamtpaket ) ist sehr bequem zu benutzen und ist Super integriert. Da geht es auch schon los. Es gibt quasi keinen Port für Windows von SDL. Ich sage mit Absicht quasi da es null Integriert ist. Es gibt nicht mal ein Setup das gleich Visual Studio einrichtet und die beigelegten Projekt Files für VS sind für eine 12 Jahre alte Software ( VS6 ).
PS: SDL gibt es für Windows auch nicht einmal in einer 64bit Version.
Hast du auch mal darin programmiert, statt es dir nur anzuschauen? Google mal nach "opengl tutorial"... Vielleicht hast du ja ein anderes Verständnis von Kompliziertheit, aber ich fand DirectX schrecklich kompliziert, als ich mir angeschaut hatte. In Delphi gabs noch so ein praktischen Add-On dafür, aber bei C++? *schauder*
Tonnenweise Beispielcode, umfassende Manuals und Referenzen zu OpenGL findest du übrigens unter opengl.org sowie http://www.sgi.com/products/software/opengl/. Ich bezweifle, dass DirectX dem nur annähernd etwas entgegenhalten kann.
Und leider gibt es bei OpenGL keine Referenz Implementierung für die Hardware Hersteller. Man könnte jedes mal kotzen wenn man feststellt das seine Shader nicht auf Hardware XY Funktionieren weil jeder Hersteller die Spezifikation anders "Interpretiert". Und der große Vorteil der Erweiterung wird auch hinfällig wenn man nicht nur für einen Hardware Hersteller Entwickelt.
Von Programmierer am Di, 17. August 2010 um 13:09 #
Ja, das ist in der Tat (mMn) im Moment die einzige Linux-IDE, die aus den Kinderschuhen raus ist. Eclipse ist jedoch zunächst eine Java IDE, das spürt man noch überall, obwohl CDT schon sehr weit ist. Es war ein Guter Einwand. Ich nutze Eclipse selber, bin aber in der Eile nicht darauf gekommen es zu erwähnen So kann man sich auch selber polarisieren. Man müsste noch fairnesshalber Netbeans nennen. Jedoch halte ich nichts von Oracle.
Als ich versucht habe (bin immer noch dabei) auf Linux zu wechseln, fehlten mir sehr viele Tools.
Das ist umgekehrt nicht anders. Wenn ich mal was unter Windows zu bauen oder zu testen habe, fühle ich mich wie ein einer Art Wüste.
Mittlerweile ist das schon ganz erträglich, musste aber ziemlich viele Sachen suche und nachinstallieren. Z.B. eine Konsole mit Tabs (als Shell benutze ich noch cmd.exe), nmake Ersatz der auch mehrere Cores unterstützt (2010, da fragt man sich schon, warum Microsoft noch keine Multicoreunterstützung für Builds hat).
Wenn man lange Zeit mit einer bestimmten Toolchain gearbeitet hat, unabhängig davon mit welcher, hat man einfach alle Arbeitsabläufe darauf abgestimmt und ist daher dann damit am effektivsten und braucht bei einem Wechsel erstmal eine gefühlte Ewigkeit bevor überhaupt Grundsachen wieder klappen.
Von Linux-Programmierer am Mo, 16. August 2010 um 21:39 #
Welche Tools denn und was programmierst du? Wenn es sich nicht gerade um GUI-Programmierung in C++ handelt, kann ich Eclipse wärmstens empfehlen. Dafür gibt es tonnenweise ständig weiterentwickelte Plugins. Da ich annehme, dass du in C++ progammierst würde ich CMake benutzen, damit kann man schnell loslegen und es ist trotzdem so mächtig wie configure oder das Zeug, das bei Visual Studio dabei ist.
Der Unterschied zu Windows ist halt, dass es keine komfortablen Gesamtpakete gibt, die man mit IDEs wie Visual Studio oder Delphi vergleichen kann. Dafür sind die Editoren der IDEs unter Linux wie ich finde deutlich flexibler und angenehmer in der Bedienung. Ansonsten kann ich dir raten auch mal Netbeans und Anjuta oder KDevelop auszuprobieren. (Letztere beide falls du vorhast komplexe GUIs zu programmieren.) Uuund wenn du Probleme hast einfach mal den IRC-Chat aufmachen, in den passenden Channel wechseln, zB #eclipse, #linux oder #netbeans, und dort nach Hilfe zu fragen. (Am besten vorher die FAQs der Channels lesen, wenn du noch nie im IRC warst.)
Nicht falsch verstehen, ich weiss die Freigabe des Quellcodes durchaus zu schaetzen. Nur frage ich mich bei sowas immer, warum nicht auch die Texturen, Sound, etc. freigegeben werden? Wuerde mich mal interessieren.
Vermutlich weil sie nicht alle Rechte an den Dateien halten. Soundfiles sind gerne mal nur lizensiert. Zudem wollen sie sicherlich auch weiterhin an den alten Spielen Geld verdienen, nur die Engine ist ihnen nichts mehr wert.
Von Boah habt ihr den Quellcode ge am Mo, 16. August 2010 um 18:21 #
Hab mal in die Sources von RTCW SinglePlayer reingeschaut. Reines C! Keine Klassen kein gar nichts, nur eine unüberschaubare Anzahl an Funktionen. Da wundert mich auch nicht, dass es sich nicht lohnt den Code auf andere Systeme zu portieren. ^^
Ob die Rage auch so entwickeln und ob C bei anderen Spieleschmieden auch noch so intensiv genutzt wird? Ich finds jedenfalls grausam unübersichtlich.
Naja das trifft stets auf bei OOP zu aber sollte im Allgemeinen zu vernachlässigen sein. Der Overhead ist schon lange kein objektiver Grund mehr auf OOP zu verzichten, jedenfalls nicht bei Spielen und anderer typischer End-User-Software. Ein gescheit geschriebener Shader bzw. die Ausnutzung von Multi-Threading ist bei weitem ausschlaggebener.
P.S.: Kann es sein, dass ich Name und Betreff im ersten Kommentar vertauscht habe?
Ist zwar traurig, dass Carmack die Entwicklung der Spiele unter Linux zurückzieht, aber dennoch bin ich dankbar für die Offenheit die er bei Id weiter pflegt. Ich meine es ist ja auch irgendwo verständlich, dass für ein Unternehmen die Portierung zu Linux irgendwann unwirtschaftlich wird. Meine einzige Hoffnung ist, dass er OpenGL treu bleibt. Und die endlich in die Gänge kommende Entwicklung von OpenGL bei der Khronos Group gibt da auf jeden Fall Hoffnung.
Auf dem Foto hat John Carmack aber schon nen ganz schönen Buckel.
Kommt das vom täglichen Programmieren?
Außerdem hat er da eine offene Pepsiflasche stehen. So etwas würde ich nie machen, sondern immer den Deckel draufmachen. Denn man kann ja nie wissen, ob nichtmal ne Wespe in die Flasche fliegt.
In einer solchen Sitzposition hält ein Mensch auf seinem Arbeitsplatz wohl kaum lange durch.
Wahrscheinlich saß er für das Foto am "falschen" Rechner eines Kollegen, da sein Arbeitsplatz vielleicht so chaotisch unaufgeräumt war (nur eine Vermutung von mir). Die Fotoszene ist wohl gestellt, dafür spricht auch das gerade geöffnete, aber immer noch randvolle Cola-Fläschchen. Und natürlich der Buckel.
Das ist ein ganz schoen altes Foto - genau dieses verwendet prolinux immer, wenn es um John geht;
und jedes mal kommt es zur Diskussion ueber seine Sitzhaltung.
sie nehmen immer wieder das bild, weil es tatkraft demonstriert.
Prolinux ist bekannt dafür, dass sie alte Fotos verwenden. Nicht nur bei John tauchen so immer wieder sinnlose Diskussionen auf.
Sehe ich genau so!
Hätte man sich vor 3-4 Jahren als Ubuntu hochkam auch 100% auf Wine konzentriert, würden heute viele Spiele auch unter Linux/Wine laufen. (Mit "laufen" meine ich schon "Platinum"-Rating bei winehq - nicht Frickelsilber).
Aber nein! Es folgte diese sinnlose Diskussion, dass alles nativ, blablabla, laufen muss. Ich habe mich damals schon gefragt: WIESO? Darauf hatte auch keiner eine sinnvolle Antwort.
Es ist diese dämliche "Überheblichkeit" (es ist defacto nur Dummheit) mancher open-source Leuten, die eine strikte Trennlinie zwischen Windows und Linux machen wollen. Vor allem, die erwarten ernsthaft (!), dass sich dann manche Spielefirmen (nicht unbedingt id, die sind insgesamt nett) sich dann die Mühe machen und das Ganze auf Linux portieren ?! WTF?
Über Wine hätte vll eine sinnvolle Angleichung stattfinden können. Auch für den Enduser.
Kommentar bezieht sich auf folgendes Zitat:
" Wie die Linux-Spieleseite »LinuxGames« berichtet, sei es laut Carmack schwer, die Vorteile einer Portierung für Linux zu finden. Demnach ergeben Projekte wie Wine mehr Sinn."
Naja, wenn ich mir z.b. Starcraft II anschaue, dann läuft das mit wine deutlich langsamer als unter Windows.
Allerdings ist das kein grundsätzliches, systembedingtes Problem sondern "nur" ein Problem der Implementierung das gelöst werden kann. WINE ist halt wirklich kein Emulator.
"sondern "nur" ein Problem der Implementierung"
Dummerweiße ist das kein Problem, das leicht zu lösen ist, sondern Prinzipbedingt. Solche Probleme wird es am Ende wohl immer geben, 100%ig geht einfach nicht.
Daher wären native Lösungen vorzuziehen.
naja bin zwar kein spezialist, aber einige d3d bezogene sachen laufen auf wine auch wesentlich schneller als unter windows (ja das ist so), einige dinge aber eben auch wesentlich langsamer, so ergibt sich zusammen ein performance verlust.
ich denke nicht dass man in wine einen großen aufwand betreibt zu optimieren, man ist froh, dass die scheisse überhaupt läuft und hat genug damit zu tun den rest der noch fehlt zu implementieren.
ich denke aber es wäre durchaus möglich da einiges zu optimieren, was dann aber wohl das risiko hätte dass diese optimierungen plattformabhängig sind und das möchte man bei wine wohl auch nicht..
Viele Probleme von WINE wären nicht da, wenn WINE auch MacOSX Anwendungen laufen lassen könnte.
das wäre ja sogar deutlich einfacher zu realisieren, man müsste GNUStep nur mal weiterentwickeln.
Auch wenn ich mir recht sicher bin, das dies nur ein Trollversuch von dir ist:
"Darauf hatte auch keiner eine sinnvolle Antwort. "
Das bezeifle ich, es gibt immerhin gute Gründe warum native Lösungen vorzuziehen sind.
An der Stelle möchte ich folgende Nennen, es gibt aber natürlich noch weitere:
1. Wine ist eine in vielen fällen nutzbare Lösung, jedoch weit ab vom perfekten. Praktisch jeder Wine-Release bringt regressions, etwas das sich auch kaum verhindenr lässt, ist doch auch Windows davon betroffen. Wine ist jedoch, auch durch die viele Arbeit die darin zu investieren ist, um mit der Windowswelt schritt zu halten, viel stärker davon betroffen. Praktisch jeder Commit in Wine bringt quasi zwei neue Funktionen, und zerstört eine alte.
2. Die Anwendungen laufen nativ zumeist deutlich schneller
3. Nur wenige Anwendungen und spiele laufne mit Wine gut. Die großen Namen wie World of Warcraft täuschen darüber hinweg, das die meisten Spiele nur mäßig, schlecht oder garnicht funktionieren. Dies ist auch kein Umstand, der leicht zu lösen ist, das Windowsgesamtsystem ist komplex, und schon kleine Abweichungen im Verhalten können ernsthafte Probleme in den Spielen hervorrufen.
Dies ist auch in den Unterschieden von Linux und Windows begründet. Viele kleine und größere Unterschiede (Casesensitive Dateisysteme, netzwerkfähige GUI mit Layertechnik, starke Variationen von Systemlibversionen, Unterstützung für mehr als eine Prozessorfamilie usw.) machen es auch praktisch unmöglich Wine wirklich stabil zu bekommen.
Wine ist in Ordnung, als Hilfe ist es super, aber wirklich gut wird damit nie alles laufen. Die Anforderung, Windows in einem nicht-Windows System perfekt nachzubilden, ist einfach zu hoch, als das es wirklich möglich wäre.
Ein Angleichung, unter Bewahrung der Besonderheiten, ist schlicht nicht möglich. Es sind einfach Äpfel und Birnen. Das wird einfach nie das gleiche werden, auch nicht mit einer Zuckerglasur.
Nebenher: Wären die Spieel Open Source, würden User meist die Portierung durchführen. Alle spiele, deren Quellcode freigegeben wurden, sind kurz darauf als Multiplattformtitel verfügbar gewesen (Descent, die ID Spiele usw.)
Kein Trollversuch.
Natürlich sind native Lösungen immer besser als Layer-Lösungen. Aber welche Firma bringt denn ernsthaft eine native Version raus für <3% potentielle Käufer? Sogar bei id war es zuerst ein Third-Party-Port auf Linux.
Zu deinen Punkten 1-3: Klar, das sind die allgemeinen Probleme mit Wine.
Aber dennoch sehe ich Wine als die Zukunft des (kommerziellen) Spielens unter Linux. War es vor 4 Jahren, wird es hws auch in 4 Jahren sein.
"Aber dennoch sehe ich Wine als die Zukunft des (kommerziellen) Spielens unter Linux. War es vor 4 Jahren, wird es hws auch in 4 Jahren sein."
Das sehe ich genauso.
Ich nutze unter Linux mit Wine noch ein paar Windowsspiele, u.a. uralte Mahjongg-Spiele und das noch ältere Civilization II.
Civ II läuft mittlerweile mit Wine ganz hervorragend, immer vorausgesetzt, man schaltet alles ab, was irgendwie mit "Sound" zusammenhängt.
In diesem Zusammenhang sollte man auch nicht vergessen, dass es nicht immer möglich ist, alte native Linuxspiele auf aktuellen Linuxdistributionen zu spielen. Die Rückwärtskompatibilität ist mitunter katastrophal (vor allem bei Distros, die noch nie etwas von "compat"-Paketen gehört haben). Von daher bräuchte es fast schon ein "Line".
Ich weiß nicht was ihr habt... ich programmiere seit etlichen Jahren unter Windows. Als ich versucht habe (bin immer noch dabei) auf Linux zu wechseln, fehlten mir sehr viele Tools. Alleine Visual Studio Ultimate ist rundum ein gelungenes Paket, dass nur sehr schwer zu ersetzen ist. A
Wenn man auf irgendwelche Anwendungen fixiert ist, die unter Windows laufen, tut man sich natürlich keinen Gefallen, erst recht nicht wenn diese Anwendungen von Microsoft kommen. Es gibt, gerade was Softwareentwicklung betrifft, eine breite Auswahl an Anwendungen unter Linux. Wenn nun nicht exakt die Anwendung, die man unter Windows genutzt hat, zufälligerweise auch unter Linux vorhanden ist, wird man gerade bei IDE's immer die ein oder andere Sache vermissen, einfach weil diese Anwendungen so umfangreich sind. Lässt man sich trotzdem darauf ein, wird man dafür früher oder spätere andere Dinge, die man bei der Windows Anwendung eben nicht hat, kennen und schätzen lernen. So ist es mit einer ganzen Menge Anwendungen.
Das Problem vieler Windows User ist doch, sie suchen unter Linux z.B. nicht nach Bildbearbeitungsprogrammen oder IDE's, sondern nach einer Alternative zu Visual Studio und Adobe PS. Wenn das Linux Pendant dann eine Sache nicht kann, die man unter Windows gewohnt ist, heißt es sofort, man könne mit dem Betriebssystem nicht arbeiten.
Naja, hast du dir mal das DirectX SDK angeschaut? Das ist unglaublich umfangreich, bringt viele Beispiele und eine umfassende Dokumentation mit - wo bekomme ich sowas für OpenGL?
Du vergleichst da wohl gerade Äpfel und Birnen. OpenGL ist nur eine Alternative zu Direct3D, nicht zu dem ganzen Paket DirectX. Du kannst höchsten die Kombination aus SDL und OpenGL sinnvoll mit DirectX vergleichen
Das ändert nichts an der Aussage.
Bitte bring nicht SDL ins Spiel. Damit kannst du dir nur selber ins Knie schießen.
Und wenn du es doch willst dann sage ich dir gleich SDL wird verlieren.
DirectX (damit meine ich das Gesamtpaket
) ist sehr bequem zu benutzen und ist Super integriert. Da geht es auch schon los. Es gibt quasi keinen Port für Windows von SDL. Ich sage mit Absicht quasi da es null Integriert ist. Es gibt nicht mal ein Setup das gleich Visual Studio einrichtet und die beigelegten Projekt Files für VS sind für eine 12 Jahre alte Software ( VS6 ).
PS: SDL gibt es für Windows auch nicht einmal in einer 64bit Version.
Hast du auch mal darin programmiert, statt es dir nur anzuschauen? Google mal nach "opengl tutorial"... Vielleicht hast du ja ein anderes Verständnis von Kompliziertheit, aber ich fand DirectX schrecklich kompliziert, als ich mir angeschaut hatte. In Delphi gabs noch so ein praktischen Add-On dafür, aber bei C++? *schauder*
Tonnenweise Beispielcode, umfassende Manuals und Referenzen zu OpenGL findest du übrigens unter opengl.org sowie http://www.sgi.com/products/software/opengl/. Ich bezweifle, dass DirectX dem nur annähernd etwas entgegenhalten kann.
Schau mal in das MSDN ...
Und leider gibt es bei OpenGL keine Referenz Implementierung für die Hardware Hersteller. Man könnte jedes mal kotzen wenn man feststellt das seine Shader nicht auf Hardware XY Funktionieren weil jeder Hersteller die Spezifikation anders "Interpretiert". Und der große Vorteil der Erweiterung wird auch hinfällig wenn man nicht nur für einen Hardware Hersteller Entwickelt.
Es ist ja nicht so dass ich fixiert bin.
KDevelop,Code::Blocks,Anjuta etc.. haben nicht mal ansatzweise die Qualität von Visual Studio.
Wie wärs mit Eclipse?
Ja, das ist in der Tat (mMn) im Moment die einzige Linux-IDE, die aus den Kinderschuhen raus ist. Eclipse ist jedoch zunächst eine Java IDE, das spürt man noch überall, obwohl CDT schon sehr weit ist. Es war ein Guter Einwand. Ich nutze Eclipse selber, bin aber in der Eile nicht darauf gekommen es zu erwähnen
So kann man sich auch selber polarisieren. Man müsste noch fairnesshalber Netbeans nennen. Jedoch halte ich nichts von Oracle.
Das ist umgekehrt nicht anders. Wenn ich mal was unter Windows zu bauen oder zu testen habe, fühle ich mich wie ein einer Art Wüste.
Mittlerweile ist das schon ganz erträglich, musste aber ziemlich viele Sachen suche und nachinstallieren.
Z.B. eine Konsole mit Tabs (als Shell benutze ich noch cmd.exe), nmake Ersatz der auch mehrere Cores unterstützt (2010, da fragt man sich schon, warum Microsoft noch keine Multicoreunterstützung für Builds hat).
Wenn man lange Zeit mit einer bestimmten Toolchain gearbeitet hat, unabhängig davon mit welcher, hat man einfach alle Arbeitsabläufe darauf abgestimmt und ist daher dann damit am effektivsten und braucht bei einem Wechsel erstmal eine gefühlte Ewigkeit bevor überhaupt Grundsachen wieder klappen.
Welche Tools denn und was programmierst du? Wenn es sich nicht gerade um GUI-Programmierung in C++ handelt, kann ich Eclipse wärmstens empfehlen. Dafür gibt es tonnenweise ständig weiterentwickelte Plugins. Da ich annehme, dass du in C++ progammierst würde ich CMake benutzen, damit kann man schnell loslegen und es ist trotzdem so mächtig wie configure oder das Zeug, das bei Visual Studio dabei ist.
Der Unterschied zu Windows ist halt, dass es keine komfortablen Gesamtpakete gibt, die man mit IDEs wie Visual Studio oder Delphi vergleichen kann. Dafür sind die Editoren der IDEs unter Linux wie ich finde deutlich flexibler und angenehmer in der Bedienung. Ansonsten kann ich dir raten auch mal Netbeans und Anjuta oder KDevelop auszuprobieren. (Letztere beide falls du vorhast komplexe GUIs zu programmieren.) Uuund wenn du Probleme hast einfach mal den IRC-Chat aufmachen, in den passenden Channel wechseln, zB #eclipse, #linux oder #netbeans, und dort nach Hilfe zu fragen. (Am besten vorher die FAQs der Channels lesen, wenn du noch nie im IRC warst.)
Nicht falsch verstehen, ich weiss die Freigabe des Quellcodes durchaus zu schaetzen. Nur frage ich mich bei sowas immer, warum nicht auch die Texturen, Sound, etc. freigegeben werden? Wuerde mich mal interessieren.
Vermutlich weil sie nicht alle Rechte an den Dateien halten. Soundfiles sind gerne mal nur lizensiert.
Zudem wollen sie sicherlich auch weiterhin an den alten Spielen Geld verdienen, nur die Engine ist ihnen nichts mehr wert.
Hab mal in die Sources von RTCW SinglePlayer reingeschaut. Reines C!
Keine Klassen kein gar nichts, nur eine unüberschaubare Anzahl an Funktionen. Da wundert mich auch nicht, dass es sich nicht lohnt den Code auf andere Systeme zu portieren. ^^
Ob die Rage auch so entwickeln und ob C bei anderen Spieleschmieden auch noch so intensiv genutzt wird? Ich finds jedenfalls grausam unübersichtlich.
Ja, wird so genutzt.
Objekte haben für Spiele die unangenehme Eigenschaft, dass sie idR. etwas mehr Speicher brauchen und ein wenig langsamer sind.
Natürlich gibt es auch den umgekehrten Effekt, aber meistens ist es eben so herum.
Die mad
Naja das trifft stets auf bei OOP zu aber sollte im Allgemeinen zu vernachlässigen sein. Der Overhead ist schon lange kein objektiver Grund mehr auf OOP zu verzichten, jedenfalls nicht bei Spielen und anderer typischer End-User-Software.
Ein gescheit geschriebener Shader bzw. die Ausnutzung von Multi-Threading ist bei weitem ausschlaggebener.
P.S.: Kann es sein, dass ich Name und Betreff im ersten Kommentar vertauscht habe?
Ja Heute aber schau mal von wann die Spiele sind. Wolfenstein ist aus dem Jahre 2001 und ET aus 2003.
Hier auch noch mal die Systemanforderungen.
400 MHz CPU, 128 MB RAM, 16 MB RAM Grafikkarte