Archiv verlassen und diese Seite im Standarddesign anzeigen : Linux Umfrage auf der Gamestar Hauptseite!!!
zu UT2003 / UT2004:
Das hatten wir schon öffters. Die Anforderungen dieses Spiels sind gar nicht so hoch wie man glaubt. Ne GeForce 4 reicht locker. Das einzige was man braucht ist ein schneller Prozessor. Ich hab z.B. einen XP3200 und damit kann man alles aktivieren und merkt gar nichts davon das da ein Wrapper arbeitet. Auch bei zig Bots und riesen Maps nicht.
Alles besteht aus Bausteinen, auch DirectX, wenn es anders wäre, dann wäre der Code nicht mehr wartbar.
Und die Unix Philosophie ist mir wichtiger, lieber spezialisierte Dinge die etwas richtig machen, als ein Ding das versucht alles irgendwie hinzukleistern.
Stimmt zwar, aber die Bausteine werden in einem Paket geliefert, mit einem Stapel Dokumentation, aus einer Hand.
Abgesehen davon, würde mir die Unix Philosophie nicht passen, würde ich kein Linux verwenden. Hier geht's aber auch um Marketing, und im Spielemarkt interessiert sich kein Schwein für die Unix Philophie, die wollen eine Lösung, keine Philosophien.
Schon mal ins CVS geschaut?
Solange da mehr passiert als in der Mailingliste... Aber im Ernst, selbst Ryan Gordon sagte unlängst, die Entwicklung von OpenAL sei träge und nicht zielführend.
Bildformate zu laden ist nicht die Aufgabe von OpenGL, dazu
gibt es spezialisierte Bibliotheken wie z.b. libpng für PNG Bilder.
Das ist zwar eigentlich schön, aber kompletter Quatsch für Spieleentwickler. Niemand hat Lust - gerade in so einem zeitkritischen Markt - für tausend Dinge kleine mehr oder weniger nützliche Libraries zu suchen, auf Tauglichkeit zu prüfen, die Lizenz zu prüfen, eine native Windows-Version zu suchen (nicht Cygwin), um dann festzustellen dass die API ******e ist, oder ein Feature fehlt, oder die Library überladen ist, oder nicht vernünftig optimiert ist...
Und dann willst du die Theora Library in deine Spielebibliothek integrieren wie
die PNG Library in OpenGL oder was?
Du hast es erfasst. Da 99.9% aller Spiele einen Videoplayer benötigen, halte ich es für absolut gerechtfertigt, ihn zu integrieren. Ebenso wie das Laden von Bildern und Texturen von jedem Spiel ohnehin benötigt wird (Du beschwerst Dich ja auch nicht, dass OpenAL Samples laden kann, obwohl es auch dafür spezielle Libraries gäbe).
Also so etwas wie OpenGL oder Direct3d von Grund auf neu zu progammieren dürfte Jahre dauern und kaum etwas bringen, wenn OpenGL
mehr als ausreichend ist und sich schon längst bewährt hat.
Ich habe nicht gesagt, dass man alles neu schreiben müsste. Nur sollte man die komplexen Funktionen von OpenGL leichter erreichbar machen.
Die Zeiten in denen man derart massiv Gebrauch von Extensions wie J. Carmack machen mußte sind seit OpenGL 2.0 vorbei.
Wenn man heute ein Spiel entwickelt, das in 3-4 Jahren erst fertig ist,
dann kann man darauf aufbauen, das bis dahin für jede moderne Grafikkarte ausgereifte OpenGL 2.0 Treiber zur Verfügung stehen werden.
Schön wär's. Aber Extensions wird's auch bei OpenGL 2 noch geben (oder denkst Du, mit OpenGL 2 wäre schon alles erreicht!?). Abgesehen davon muss eine GraKa nicht zwingen alle Features von OpenGL 2 in Hardware können, um sich "OpenGL 2 kompatibel" nennen zu dürfen. Bei Direct3D schon...
Ein Soundshader?
Was soll denn das sein?
Ein Miniprogramm, das den Sound verändert - zB die Modulation von Samples, um sie abwechslungreicher scheinen zu lassen, oder spezielle Echo- und Reverbeffekte, die aufgrund der Beschaffenheit des Reflektors den Klang verändern, Klänge durch bestimmte Materialien dämpfen etc...
So etwas zu liefern ist Teil einer 3d Engine und nicht einer 3d API!
Das ist im Moment zwar üblich, muss aber nicht unbedingt sein. Zumindest kann man sich überlegen, wie man es dem Entwickler erleichtern kann, eine Partikelengine zu schreiben (indem man bestimmte Funktionen integriert, die extrem häufig bei Partikelsystemen vorkommen).
Um mal Direct3d herauszupicken. OpenGL ist gegenüber Direct3d TECHNISCH überlegen.
Stimmt. Aber es hat Nachteile, die auch mit OpenGL 2 nicht abgeschafft werden. Und es hat auch einen Grund, warum nur sehr wenige Entwickler (id) eine OpenGL - basierende Engine bauen können, die diese Überlegenheit auch demonstriert.
Wenn du einen fertigen Game Kit zum Spiele zusammenbasteln willst,
dann kauf dir eine fertige Engine.
Mal abgesehen davon, dass Torque derb veraltet ist, rede ich hier nicht von einer fertigen Engine, sondern von einer Abkürzung auf dem Weg dorthin.
Da deine Game API Sammlung immer extra installiert werden muß,
wird DirectX unter Windows immer die erste Wahl für Spieleentwickler sein, denn das wird mit Windows mitgeliefert.
Tja, dann stellt sich die Frage, warum jedes Spiel auf dem Markt zusätzlich noch einen DirectX Installer mit auf der CD hat. Als ich das letzte Mal geschaut habe, war auf einem frisch installierten Win2k nämlich noch kein DX9.0c mit drauf. Und wenn DirectX sowieso auf der CD ist, können die Hersteller auch den Installer für eine andere Library mit draufräumen.
Stimmt zwar, aber die Bausteine werden in einem Paket geliefert, mit einem Stapel Dokumentation, aus einer Hand.
Wenn das alles ist, dann brauchst du nur so etwas wie die Linux Standard Base, nur halt für Spiele und das Crossplattform.
Also so ne Art:
"Crossplattform Game Standard Base Bekenntnis"
Da packst du dann OpenGL, OpenAL, SDL und noch ein paar Format Librarys rein und fertig, ob das von der Industrie dann angemommen wird steht auf einem anderen Blatt.
Solange da mehr passiert als in der Mailingliste... Aber im Ernst, selbst Ryan Gordon sagte unlängst, die Entwicklung von OpenAL sei träge und nicht zielführend.
Link?
Das ist zwar eigentlich schön, aber kompletter Quatsch für Spieleentwickler. Niemand hat Lust - gerade in so einem zeitkritischen Markt - für tausend Dinge kleine mehr oder weniger nützliche Libraries zu suchen, auf Tauglichkeit zu prüfen, die Lizenz zu prüfen, eine native Windows-Version zu suchen (nicht Cygwin), um dann festzustellen dass die API ******e ist, oder ein Feature fehlt, oder die Library überladen ist, oder nicht vernünftig optimiert ist...
Wieviele Basis Datenloader brauchst du denn wirklich?
Du brauchst ein Format für Texturen, eines für Sounddaten und eines für 3d Mesh Modelle, das wars dann aber auch schon.
Um weitere Gamespezifische Dinge zu laden integriert man den entsprechenden Support in die Engine.
Du hast es erfasst. Da 99.9% aller Spiele einen Videoplayer benötigen, halte ich es für absolut gerechtfertigt, ihn zu integrieren. Ebenso wie das Laden von Bildern und Texturen von jedem Spiel ohnehin benötigt wird (Du beschwerst Dich ja auch nicht, dass OpenAL Samples laden kann, obwohl es auch dafür spezielle Libraries gäbe).
OpenAL ahmt die OGG Libray aber nicht nach, sondern benutzt diese nur.
Das einzige was wirklich in OpenAL fest eingebaut wurde ist vielleicht der Support für Wav Dateien, aber so ein Grundlegendes Basisformat gibt es auch bei OpenGL -> *.rgb.
Ich habe nicht gesagt, dass man alles neu schreiben müsste. Nur sollte man die komplexen Funktionen von OpenGL leichter erreichbar machen.
Vieles ist mit den neuen OpenGL Versionen schon leichter geworden,
bestes Beispiel wäre z.B. Multi Texturing.
Laut den ersten OpenGL 2.0 Spezikationen sollte es so etwas wie ein
OpenGL 2.0 Core geben (oder so ähnlich, weiß den genauen namen nicht mehr), aber das wurde wieder verworfen, die Entwickler dürften am besten wissen warum.
Schön wär's. Aber Extensions wird's auch bei OpenGL 2 noch geben (oder denkst Du, mit OpenGL 2 wäre schon alles erreicht!?).
Mag sein, aber in OpenGL 2 sind jetzt genau die Dinge drin, die schon lange dringend notwendig waren und auf welche man auch nicht einfach bei modernen Spielen verzichten konnte.
Die anderen Effekte die demnächst möglich werden, sind nicht so grundlegend wie die Unterstützung für programmierebare Vertex und Pixelshader.
Diese neuen Features sind also nur Optional notwendig, wofür Extensions ausreichen.
Außerdem dauert es Jahre bis der Marktanteil an Grafikkarten der bestimmte Effekte ermöglicht groß genug ist, daß man diese Effekte auch ausgiebig nutzen kann.
Selbst Doom 3 verwendet nur eine Recht kleine Anzahl an speziellen OpenGL
Funktionen/Effekten, am ergiebigsten dürften wohl die Bump Mapping Funktionen genutzt werden, aber die gab's schon in OpenGL 1.3.
Abgesehen davon muss eine GraKa nicht zwingen alle Features von OpenGL 2 in Hardware können, um sich "OpenGL 2 kompatibel" nennen zu dürfen. Bei Direct3D schon...
Das ist reine Definitionssache und ein kleines Problem.
Ein Miniprogramm, das den Sound verändert - zB die Modulation von Samples, um sie abwechslungreicher scheinen zu lassen, oder spezielle Echo- und Reverbeffekte, die aufgrund der Beschaffenheit des Reflektors den Klang verändern, Klänge durch bestimmte Materialien dämpfen etc...
Gut, das wäre ein Gebiet für OpenAL.
Das ist im Moment zwar üblich, muss aber nicht unbedingt sein. Zumindest kann man sich überlegen, wie man es dem Entwickler erleichtern kann, eine Partikelengine zu schreiben (indem man bestimmte Funktionen integriert, die extrem häufig bei Partikelsystemen vorkommen).
Tja, leider ist das nicht so einfach, da z.B. die Physik und Partikelverwaltung
meist ziemlich stark mit der Engine verbunden ist bzw. davon abhängig ist.
Und eine Funktion um einen Sprite, Partikel etc. schnell darzustellen gibts
in OpenGL schon, der Rest ist die Ausrichtung dieses Partikels auf die Blickrichtung des Users, sowie die Kräfteeinwirkung bzw. Wegberechnung
aber das sind halt alles Dinge die in eine Engine gehören und nicht in eine Basis API.
D.h. natürlich kann man alles mögliche in die Basis Pakete OpenGL, OpenAL und SDL reinbauen, aber das ist nicht deren Ziel, denn wenn du das machst, dann kommt am Ende eine Engine raus.
Tja, dann stellt sich die Frage, warum jedes Spiel auf dem Markt zusätzlich noch einen DirectX Installer mit auf der CD hat. Als ich das letzte Mal geschaut habe, war auf einem frisch installierten Win2k nämlich noch kein DX9.0c mit drauf. Und wenn DirectX sowieso auf der CD ist, können die Hersteller auch den Installer für eine andere Library mit draufräumen.
Reingefallen. :D
Und genau das ist der Punkt, wenn du sowiso alles auf CD mitlieferst, dann kannst du auch die PNG Tiff, OGG, SDL und sonstige Libraries mitliefern.
flashbeast
25.11.04, 22:41
merkt gar nichts davon das da ein Wrapper arbeitet.
das mag daran liegen, dass kein wrapper verwendet wird. ist eine annahme gewesen, die sich als falsch erwiesen hat. quelle unbekannt.
Bezüglich Ryan Gordon und OpenAL.
Ich habe jetzt mal mit google etwas danach gesucht und
was ich gefunden habe klingt durchweg positiv:
Da steht, das OpenAL deutlich unbeschwerlicher zu verwenden ist,
als Plattformspezifische APIs und an Boden gewinnt.
http://www.linuxworld.com/story/44106.htm?DE=1
Und hier steht, das Apple sich jetzt um eine eigene OpenAL Implementierung
kümmert worüber Ryan Gordon sehr froh ist und daher seine Arbeit an einer eigenen OpenAL Implementierung für den Mac einstellt um sich auf wichtigeres zu konzentrieren:
http://www.insidemacgames.com/news/story.php?ArticleID=9909
Und wenn man noch berücksichtig das wichtige Open Source Projekte
auf OpenAL umgestellt haben, z.B. FlightGear dann kann man sehr zuversichtlich sein, das die Entwicklung an OpenAL voranschreitet.
Wenn das alles ist, dann brauchst du nur so etwas wie die Linux Standard Base, nur halt für Spiele und das Crossplattform.
Also so ne Art:
"Crossplattform Game Standard Base Bekenntnis"
Da packst du dann OpenGL, OpenAL, SDL und noch ein paar Format Librarys rein und fertig, ob das von der Industrie dann angemommen wird steht auf einem anderen Blatt.
Ein "Produkt" mit fetzigem Namen und CI muss es sein, nehmen wir mal "Unity" - mit coolem Logo, stylischer und informativer Internetseite und einem professionellen "Alles aus einer Hand"-Gefühl. Für die Akzeptanz ist das schon mal sehr wichtig...
Ansonsten hatte ich das nicht ganz unähnlich angedacht. Nur halt, dass zu einem bestimmten Zeitpunkt zB OpenAL aus dem CVS gerupft wird, eventuell ein paar Anpassungen hier und da, das ganze heftig optimieren und profilen, ausgewählte Support Libs dazu (libogg, libvorbis - oder schnellere Alternativen), neue Header schreiben (um die Funktionen logisch neu zu gruppieren und die Loader einzubinden), ein paar Abkürzungen basteln, und eine einheitliches Schema für die Funktionsbennenungen draufklatschen. Die Header hießen dann zB UnityAudio.h, UnityAudio3D.h, UnityAudioShader.h usw.
Das Ganze macht man ähnlich mit OpenGL, wirft ein paar Helper dazu (OpenEXR Loader und so), und nennt es Unity3D oder UnityGL. Das gleiche würde man dann noch mit UnityControl (DirectInput), UnityVideo (Bink), UnityNet und so weiter machen, die API kann dabei ja durchaus OpenAL/ OpenGL entliehen sein.
Am Ende compiliert man das alles und erhält eine Reihe entsprechend benannter .so oder .dll Dateien, und das ist Unity. Das UnitySDK hätte noch die Header, Dokumentation und ein paar Samples und Tools dabei.
Unity würde dann parallel zu den enthaltenen Libs weiterentwickelt (nur Fehler ausmerzen und optimieren - keine neuen Features!), und ein Nachfolger würde geplant, Unity 2, der mit der ersten Version nicht kompatibel sein muss, aber koexistieren kann.
Das mag nicht unbedingt optimal scheinen, weil dann Unix-Zocker gleichzeitig mehr oder weniger redundante Libs installiert hätten (haben wir aber doch sowieso immer), aber für Spieleentwickler wären es zumindest keine beweglichen Ziele mehr. Und Festplattenplatz eh kostet nichts...
Link?
Wenn ich das noch wüsste - aber da ich schon an die 1000 Bookmarks habe, bräuchte ich schon wieder Bookmarks für die Bookmarks. Vielleicht bringt google was - abgesehen davon hätte ich nichts dagegen wenn es weiterentwickelt würde, ich halte OpenAL an sich für sehr mächtig.
Gut, das wäre ein Gebiet für OpenAL.
Wahrscheinlich am ehesten. Das Ganze kommt aber leider nur auf entsprechender Hardware richtig zur Geltung, mit entsprechenden Treibern (ich habe mal mit Sharc-basierenden DSP-Karten experimentiert, die könnten das - die EMU10Kx Chips dürften nicht die nötigen Funktionen und die Power haben).
Ein "Produkt" mit fetzigem Namen und CI muss es sein, nehmen wir mal "Unity" - mit coolem Logo, stylischer und informativer Internetseite und einem professionellen "Alles aus einer Hand"-Gefühl. Für die Akzeptanz ist das schon mal sehr wichtig...
Ansonsten hatte ich das nicht ganz unähnlich angedacht.
Du willst komplett neue Pakete schnüren und diese auch noch verändern,
ich würde nur einen Game API Sammlung Standard basierend auf bestehendem definieren.
Ich glaube letzteres ist einfacher, für den Standard kannst du dir genauso gut einen fetzigen Namen ausdenken, wenn es denn unbedingt sein muß.
Außerdem hat meine Methode den Vorteil, das jeder Distributor
selber aussuchen kann wie er den Standard umsetzt und das sich so etwas viel leichter in ein bestehendes System einfügt.
Für die Windows Plattform kann man dann noch ein Zip Paket zum downloaden schnüren, bei dem alles notwendige, außer die OpenGL Treiber (und vermutlich auch OpenAL) die sind nämlich Hardwaregebunden drin ist.
Im Prinzip würde der Standard also so lauten:
Der Standard UnitySDK besteht aus:
- der SDL Lib Version 1.2.7
- OpenGL 2.0
- OpenAl 1.0
- libPNG Library Version X.y
- LibOgg Library Version X.y
....
Und die Dateien sind hier und da im System zu finden.
Und fertig, mehr ist nicht notwendig.
Nur halt, dass zu einem bestimmten Zeitpunkt zB OpenAL aus dem CVS gerupft wird, eventuell ein paar Anpassungen hier und da, das ganze heftig optimieren und profilen, ausgewählte Support Libs dazu (libogg, libvorbis - oder schnellere Alternativen), neue Header schreiben (um die Funktionen logisch neu zu gruppieren und die Loader einzubinden), ein paar Abkürzungen basteln, und eine einheitliches Schema für die Funktionsbennenungen draufklatschen. Die Header hießen dann zB UnityAudio.h, UnityAudio3D.h, UnityAudioShader.h usw.
Das Ganze macht man ähnlich mit OpenGL, wirft ein paar Helper dazu (OpenEXR Loader und so), und nennt es Unity3D oder UnityGL. Das gleiche würde man dann noch mit UnityControl (DirectInput), UnityVideo (Bink), UnityNet und so weiter machen, die API kann dabei ja durchaus OpenAL/ OpenGL entliehen sein.
Furchtbar. http://www.linuxforen.de/ubb/icons/icon13.gif
Vergiß es, so etwas setzt sich nie und nimmer durch.
Die Entwickler kennen ihre OpenGL Library und die haben auch keine Lust
wegen jedem geänderten Funktionsnamen umzulernen.
Es ist schon ein Graus genug, das Apple in MacOS X die Header für OpenGL umbenannt hat.
Am Ende compiliert man das alles und erhält eine Reihe entsprechend benannter .so oder .dll Dateien, und das ist Unity. Das UnitySDK hätte noch die Header, Dokumentation und ein paar Samples und Tools dabei.
Samples, Doku und Tools kannst du auch bei obiger Standard Definierungsmethode anbieten. Siehe Linux Standard Base, da gibts auch ein
paar Sachen zum Downloaden.
Unity würde dann parallel zu den enthaltenen Libs weiterentwickelt (nur Fehler ausmerzen und optimieren - keine neuen Features!), und ein Nachfolger würde geplant, Unity 2, der mit der ersten Version nicht kompatibel sein muss, aber koexistieren kann.
Die Beseitigung von Fehlern sollte man den eigentlichen Projekten überlassen und aus diesem Grund veränder man auch nicht die Header und Funktionsnamen.
Es reicht, die Versionsnummer des Standards anzuheben, falls neue Versionen der einzelnen Teile des Standards vorhanden sind.
Das mag nicht unbedingt optimal scheinen,
Es ist schlimmer als suboptimal.
weil dann Unix-Zocker gleichzeitig mehr oder weniger redundante Libs installiert hätten
Eben.
(haben wir aber doch sowieso immer),
Nein, nicht unbedingt.
Du kannst auch ab und zu die bei Spielen mitgelieferten Libs in den Gameverzeichnissen löschen und durch einen Link auf die eigentliche lib des Hauptsystems verlinken.
aber für Spieleentwickler wären es zumindest keine beweglichen Ziele mehr. Und Festplattenplatz eh kostet nichts...
C Librarys sind, sofern die Minor Releases abwärtskompatibel bleiben (was normal ist) keine beweglichen Ziele.
Wenn du ein Spiel für die SDL 1.2.4 compilierst, dann ist es kein Problem,
die SDL 1.2.4 durch die SDL 1.2.7 auszutauschen, das Spiel wird immer noch laufen.
Vielleicht bringt google was
Siehe oben, über OpenAL gibt's nur positives.
Wahrscheinlich am ehesten. Das Ganze kommt aber leider nur auf entsprechender Hardware richtig zur Geltung, mit entsprechenden Treibern (ich habe mal mit Sharc-basierenden DSP-Karten experimentiert, die könnten das - die EMU10Kx Chips dürften nicht die nötigen Funktionen und die Power haben).
Wenn die notwendige Hardware eh noch nicht vorhanden ist, dann ist es mühsig über Soundshader Support zu diskutieren.
Im Prinzip würde der Standard also so lauten:
Der Standard UnitySDK besteht aus:
- der SDL Lib Version 1.2.7
- OpenGL 2.0
- OpenAl 1.0
- libPNG Library Version X.y
- LibOgg Library Version X.y
....
Und die Dateien sind hier und da im System zu finden.
Und fertig, mehr ist nicht notwendig.
Tolle Idee! Und würde, genau wie LSB, in der Realität gar nichts bringen... Weil, wie Du eventuell weißt, trotz LSB fast alle komerziellen Programme nur auf ausgewählten (LSB-konformen) Distros laufen (obwohl andere auch LSB-konform sind). Siehe: Softimage|XSI, Alias Maya, IFX Amazon - viel Spaß bei dem Versuch, die auf was Anderem als RH7.3-9.0 oder FC1 zum Laufen zu bewegen (es ist möglich, mit diversen Voodoo-Ritualen - aber nicht OOTB).
Furchtbar.
Vergiß es, so etwas setzt sich nie und nimmer durch.
Die Entwickler kennen ihre OpenGL Library und die haben auch keine Lust
wegen jedem geänderten Funktionsnamen umzulernen.
Es ist schon ein Graus genug, das Apple in MacOS X die Header für OpenGL umbenannt hat.
Wer sagt denn, dass ich die OpenGL Funktionsnamen ändern will? Ich rede davon, die Funktionsnamen der Support-Libs zu ändern (in dem Fall OpenEXR), damit sie in's Schema passen - und die API von OpenEXR ist nicht nur extrem kompiliziert, die kennt zudem auch sowieso kaum ein Spieleentwickler, folglich muss sich keiner umgewöhnen. Und wenn so viele Spieleentwickler mit der API von SDL vertraut wären, hätten wir die ganze Diskussion wohl gar nicht und würden jetzt HL² oder NFS:U2 unter Linux spielen - nativ!
Sorry, Du schätzt den Markt falsch ein. Eine freie "Definition", ein Blatt Papier, auf dem steht, was wie auszusehen haben sollte - das setzt sich nicht durch, weil's in der Realität nirgends richtig funktionieren wird...
Die Unix-Grundsätze, spezialisierte Tools für spezielle Aufgaben, hat in der Welt der Spielentwicklung (oder fast der gesammten komerziellen Softwareentwicklung) keine Gültigkeit. Da will man einfache, klare, schnelle und funktionierende Lösungen, 'könnte vielleicht laufen' ist genausowenig hilfreich, wie 12 verschiedene Libraries mit zum Spiel zu packen, für den Fall, das ein Distributor sich nicht exakt an die Spezifikation hält. Oder man kompiliert gleich alles statisch, um sicher zu gehen - hälst Du das etwa für erstrebenswert?
Samples, Doku und Tools kannst du auch bei obiger Standard Definierungsmethode anbieten. Siehe Linux Standard Base, da gibts auch ein
paar Sachen zum Downloaden.
Das löst aber mein oben angeführtes Problem auch nicht...
Die Beseitigung von Fehlern sollte man den eigentlichen Projekten überlassen und aus diesem Grund veränder man auch nicht die Header und Funktionsnamen.
Es reicht, die Versionsnummer des Standards anzuheben, falls neue Versionen der einzelnen Teile des Standards vorhanden sind.
Die Beseitigung kann man (zum Teil) den eigentlichen Projekten überlassen, nur muss man die Änderungen integrieren. Und die geänderten Header sind da das kleinste Problem, die sollten sich während einer Version sowieso nie ändern. Abgesehen davon _darf_ es nicht mehr als zwei, drei Releases pro Zyklus geben, weil wir sonst schon wieder ein "moving Target" haben. Und sei's nur beim Packaging.
Es ist schlimmer als suboptimal.
Mag sein - aber besser als jetzt ist es allemal. Und Deine Alternative ist auch keine, weil mein Vorschlag auch erlauben würde, die Entwicklung in eine komplett andere Richtung zu steuern als die Ursprungsprojekte, oder nach Bedarf Komponenten zu ersetzen (oder neuzuschreiben), ohne dass sich die für den Entwickler etwas ändert. Somit ist meine Lösung flexibler und anwenderorientierter (und Anwender sind Entwickler, dem Spieler ist völlig egal, wie das System funktioniert - solange es funktioniert).
Und, wei ich bereits anführte, Entwickler, zB bei Valve oder Blizzard, ticken anders als OpenSource Hacker.
Nein, nicht unbedingt.
Du kannst auch ab und zu die bei Spielen mitgelieferten Libs in den Gameverzeichnissen löschen und durch einen Link auf die eigentliche lib des Hauptsystems verlinken.
Mal abgesehen davon, dass dabei Probleme fast schon vorprogrammiert sind, rede ich auch nicht davon - sondern von der Tatsache, dass auf jedem Linuxrechner idR mehrere Libs installiert sind, die das Gleiche können.
C Librarys sind, sofern die Minor Releases abwärtskompatibel bleiben (was normal ist) keine beweglichen Ziele.
Wenn du ein Spiel für die SDL 1.2.4 compilierst, dann ist es kein Problem,
die SDL 1.2.4 durch die SDL 1.2.7 auszutauschen, das Spiel wird immer noch laufen.
Uplink 1.0 lief bei mir nach einem SDL Update nicht mehr (Minor Version). Also musste ich Uplink updaten, jetzt geht es wieder. Also nicht wirklich so rosarot wie Du es Dir wünschen würdest...
Wenn die notwendige Hardware eh noch nicht vorhanden ist, dann ist es mühsig über Soundshader Support zu diskutieren.
Mal abgesehen davon, dass Du OpenGL 2 verkaufen willst, obwohl es auch noch nicht da ist (nur auf Papier), kann man das auch über Software-Emulation realisieren. Außerdem gibt es im professionellen Einsatz seit Jahren Soundkarten, die auf Sharc, TigerSharc, Xilinx und Motorola DSP's basieren - im Gegensatz zu funktionierenden OpenGL 2 Treibern...
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.