Niemand braucht OpenGL Programmierer!
-
hustbaer schrieb:
Ahja: wenn dann wäre es möglich eine OGL Implementierung zu machen die alles bloss auf D3D abbildet. Umgekehrt ginge das nicht, denn man kann nicht einfach so aus dem Kernelmode raus ein Usermode Teil aufrufen.
beides nur DLLs und klar gibt es von beiden mappings auf die andere schnittstelle, ich hab frueher sowas fuer ogl->d3d3 bzw d3d5 implementiert und auch umgekehrt von d3d8 etc. auf ogl. das ist garkein problem.
-
rapso schrieb:
hustbaer schrieb:
Ahja: wenn dann wäre es möglich eine OGL Implementierung zu machen die alles bloss auf D3D abbildet. Umgekehrt ginge das nicht, denn man kann nicht einfach so aus dem Kernelmode raus ein Usermode Teil aufrufen.
beides nur DLLs und klar gibt es von beiden mappings auf die andere schnittstelle, ich hab frueher sowas fuer ogl->d3d3 bzw d3d5 implementiert und auch umgekehrt von d3d8 etc. auf ogl. das ist garkein problem.
/me sich an die alte glide wrapper zeit zurückerinner.
ps: das der thread hier noch lebt ist interessant
-
inp schrieb:
ps: das der thread hier noch lebt ist interessant
und das sogar ohne flamewars
-
rapso schrieb:
hustbaer schrieb:
Ahja: wenn dann wäre es möglich eine OGL Implementierung zu machen die alles bloss auf D3D abbildet. Umgekehrt ginge das nicht, denn man kann nicht einfach so aus dem Kernelmode raus ein Usermode Teil aufrufen.
beides nur DLLs und klar gibt es von beiden mappings auf die andere schnittstelle, ich hab frueher sowas fuer ogl->d3d3 bzw d3d5 implementiert und auch umgekehrt von d3d8 etc. auf ogl. das ist garkein problem.
wenns kein problem darstellt, warum gibs dann noch keinen anständigen dx9.0c wrapper für wine?
-
thordk schrieb:
rapso schrieb:
hustbaer schrieb:
Ahja: wenn dann wäre es möglich eine OGL Implementierung zu machen die alles bloss auf D3D abbildet. Umgekehrt ginge das nicht, denn man kann nicht einfach so aus dem Kernelmode raus ein Usermode Teil aufrufen.
beides nur DLLs und klar gibt es von beiden mappings auf die andere schnittstelle, ich hab frueher sowas fuer ogl->d3d3 bzw d3d5 implementiert und auch umgekehrt von d3d8 etc. auf ogl. das ist garkein problem.
wenns kein problem darstellt, warum gibs dann noch keinen anständigen dx9.0c wrapper für wine?
die schiere funktionsvielfalt + optimierungen für verschiedene hardware würd ich mal sagen
-
thordk schrieb:
rapso schrieb:
hustbaer schrieb:
Ahja: wenn dann wäre es möglich eine OGL Implementierung zu machen die alles bloss auf D3D abbildet. Umgekehrt ginge das nicht, denn man kann nicht einfach so aus dem Kernelmode raus ein Usermode Teil aufrufen.
beides nur DLLs und klar gibt es von beiden mappings auf die andere schnittstelle, ich hab frueher sowas fuer ogl->d3d3 bzw d3d5 implementiert und auch umgekehrt von d3d8 etc. auf ogl. das ist garkein problem.
wenns kein problem darstellt, warum gibs dann noch keinen anständigen dx9.0c wrapper für wine?
es gibt einen wrapper fuer wine, kannst ja sims spielen. die qualitaet hat dabei nichts mit technischer machbarkeit zu tun.
-
wollte ich nur sims spielen, gäbe ich das spielen ganz auf ^^ aber da ich das nicht will und kaum nen entwickler auf ogl setzt, werd ich mich wohl weiterhin mit windows rumprügeln müssen.
-
rapso schrieb:
hustbaer schrieb:
Ahja: wenn dann wäre es möglich eine OGL Implementierung zu machen die alles bloss auf D3D abbildet. Umgekehrt ginge das nicht, denn man kann nicht einfach so aus dem Kernelmode raus ein Usermode Teil aufrufen.
beides nur DLLs und klar gibt es von beiden mappings auf die andere schnittstelle, ich hab frueher sowas fuer ogl->d3d3 bzw d3d5 implementiert und auch umgekehrt von d3d8 etc. auf ogl. das ist garkein problem.
D3D ist eine DLL (bzw. mehrere), ja, aber eine von Microsoft vorgegebene.
Ein Treiber der D3D "kann" stellt bloss eine Kernelmode Schnittstelle zur Verfügung. D.h. man kann nicht einfach einen Treiber schreiben der dann alles auf OGL umlenkt.
Wenn man natürlich nicht davor zurückschreckt die D3D DLLs auszutauschen... ist das wieder eine andere Sache.
-
thordk schrieb:
wollte ich nur sims spielen, gäbe ich das spielen ganz auf ^^ aber da ich das nicht will und kaum nen entwickler auf ogl setzt, werd ich mich wohl weiterhin mit windows rumprügeln müssen.
So mies siehts mir der Wine-Unterstützung doch gar nicht aus. FlatOut 2 zum Beispiel läuft ohne Probleme und ist mE ein Direct3D 9 Spiel.
Was ich aber irgendwie lustig finde ist, dass zb EA jetzt mehr Spiele auf OS X portieren will. Also schreiben sie es erst mit Direct3D um es dann doch auf OpenGL umzumodeln.
-
thordk schrieb:
wollte ich nur sims spielen, gäbe ich das spielen ganz auf ^^ aber da ich das nicht will und kaum nen entwickler auf ogl setzt, werd ich mich wohl weiterhin mit windows rumprügeln müssen.
emm..jaaa... schoen fuer dich
-
hustbaer schrieb:
Wenn man natürlich nicht davor zurückschreckt die D3D DLLs auszutauschen... ist das wieder eine andere Sache.
ja, genau so macht man die wrapper.
-
sollen sie halt gleich in java und ogl entwickeln ^^ www.jmonkeyengine.com die engine find ich klasse, ist nen demo video von der javaone in den news.
-
rapso schrieb:
hustbaer schrieb:
Wenn man natürlich nicht davor zurückschreckt die D3D DLLs auszutauschen... ist das wieder eine andere Sache.
ja, genau so macht man die wrapper.
Geht das eigentlich auch wenn nicht die originalen D3D DLLs überschreibt sondern einfach nur gleichnamige DLLs ins gleiche Verzeichnis mit der .exe legt?
Das wäre unter Windows dann ja ein akzeptabler Weg - weil die D3D DLLs global austauschen finde ich etwas heftig.(Für WINE und Konsorten ist das natürlich egal, die müssen ja sowieso ihre eigenen D3D DLLs haben...)
-
hustbaer schrieb:
rapso schrieb:
hustbaer schrieb:
Wenn man natürlich nicht davor zurückschreckt die D3D DLLs auszutauschen... ist das wieder eine andere Sache.
ja, genau so macht man die wrapper.
Geht das eigentlich auch wenn nicht die originalen D3D DLLs überschreibt sondern einfach nur gleichnamige DLLs ins gleiche Verzeichnis mit der .exe legt?
Das wäre unter Windows dann ja ein akzeptabler Weg - weil die D3D DLLs global austauschen finde ich etwas heftig.ich hab die bisher nur lokal ausgetauscht, bzw im game ne andere dll laden lassen. die globale DLL auszutauschen waere echt evil.
-
rapso schrieb:
hustbaer schrieb:
rapso schrieb:
hustbaer schrieb:
Wenn man natürlich nicht davor zurückschreckt die D3D DLLs auszutauschen... ist das wieder eine andere Sache.
ja, genau so macht man die wrapper.
Geht das eigentlich auch wenn nicht die originalen D3D DLLs überschreibt sondern einfach nur gleichnamige DLLs ins gleiche Verzeichnis mit der .exe legt?
Das wäre unter Windows dann ja ein akzeptabler Weg - weil die D3D DLLs global austauschen finde ich etwas heftig.ich hab die bisher nur lokal ausgetauscht, bzw im game ne andere dll laden lassen. die globale DLL auszutauschen waere echt evil.
ein hardlink auf die dll wär ne gute idee, kann man per script auch umschaltbar machen so.
-
Zu der D3D<->OGL-DLL-Sache:
Aus API-Sicht sind die beiden sehr ähnlich. User/Kernelmode ist eine Backendsache.
Klar ist die Syntax der APIs anders, aber der Aufbau folgt denselben Richtlinien.Aber: D3D und OGL abstrahieren ist Unfug. Das ist nicht 1996, die Treiberleistungen unterscheiden sich nicht stark genug, um diesen Aufwand zu rechtfertigen. Bei simplen Renderings ginge es vielleicht noch, aber sobald rendertargetbasierte Effekte und Shader kommen, ists aus. Wer OS-Unabhängigkeit beim PC nehmen will, der nehme OpenGL. Plattformunabhängigkeit bezogen auf PC<->Konsole ist sowieso ohne Portierung nicht zu schaffen, Abstraktionslayer sind indiskutabel (v.a. auf Plattformen wie die PS2).
Die meisten PC-Spielehersteller verwenden D3D, weil oft die Codebase auf D3D aufbaut. Und die ersetzt man nicht mal eben
Ausserdem ist D3D im Moment deutlich angenehmer, wenn man allerneueste Effeke haben will, da die API nicht so ein Chaos ist wie bei OpenGL. Aus diesem Grund soll dieses Jahr OpenGL Longs Peak erscheinen, ein kompletter Neustart der OpenGL-API, jetzt auf Objekt- statt auf Statebasis. Für mehr siehe http://www.khronos.org/
-
dv_ schrieb:
Aber: D3D und OGL abstrahieren ist Unfug. Das ist nicht 1996, die Treiberleistungen unterscheiden sich nicht stark genug, um diesen Aufwand zu rechtfertigen.
das ist natuerlich kein unfug, jede gute engine hat einen abstraktionslayer fuer die graphik api, aber nicht nur dafuer, sondern ebenfalls fuer input, filehandling, netzwerk-lib, etc. das hat nichts mit treiberleistung zu tun, sondern mit sauberer programmierung und ist eine simple grundlage. lohnt sich natuerlich nicht wenn man schnell mal ein kleines spiel macht, aber jede engine die man kaufen kann hat all diese abstraktionslayer.
Bei simplen Renderings ginge es vielleicht noch, aber sobald rendertargetbasierte Effekte und Shader kommen, ists aus. Wer OS-Unabhängigkeit beim PC nehmen will, der nehme OpenGL. Plattformunabhängigkeit bezogen auf PC<->Konsole ist sowieso ohne Portierung nicht zu schaffen, Abstraktionslayer sind indiskutabel (v.a. auf Plattformen wie die PS2).
das ist natuerlich auch unfug. man kann ohne abtraktionslayer arbeiten wenn man eine applikation wirklich nur als fire&forget plant, aber meistens hat man einen wrapper. dass sowas sehr gut geht beweisen spiele die z.b. mit der renderware engine gemacht wurden und auf so ziemlich jedem system zu haben sind (siehe z.b. deren techdemo "burnout")
Die meisten PC-Spielehersteller verwenden D3D, weil oft die Codebase auf D3D aufbaut. Und die ersetzt man nicht mal eben
doch, macht man, wenn man einen saubere schnittstelle mittels wrapper hat. dann kann man d3d8/d3d9/d3d10/ogl/ps3/xbox umschalten wie es einem lustig ist. nicht so zu arbeiten ist wirtschaftliche dummheit. ein spiel zu entwickeln kostet immer mehr wegen dem content und der abstraktionslayer als grundlage sauberen programmierens kostet nur maintaining und im schlimmsten fall 3mann-monate an arbeit, kosten-nutzen ist erschlagend ueberzeugend.
Ausserdem ist D3D im Moment deutlich angenehmer, wenn man allerneueste Effeke haben will, da die API nicht so ein Chaos ist wie bei OpenGL. Aus diesem Grund soll dieses Jahr OpenGL Longs Peak erscheinen, ein kompletter Neustart der OpenGL-API, jetzt auf Objekt- statt auf Statebasis. Für mehr siehe http://www.khronos.org/
am angenehmsten ist direkt auf hardware zu arbeiten, bzw seinen layer darum zu bauen;)
-
Es ist kein Unsinn.
Und weils so schön passt muss ich hier auch gleich mal auf die Engine eines Freundes von mir verlinken: http://xengine.sourceforge.net/Die kann auch mit Shadern und dem ganzen Quargel umgehen.
-
rapso schrieb:
das ist natuerlich kein unfug, jede gute engine hat einen abstraktionslayer fuer die graphik api, aber nicht nur dafuer, sondern ebenfalls fuer input, filehandling, netzwerk-lib, etc. das hat nichts mit treiberleistung zu tun, sondern mit sauberer programmierung und ist eine simple grundlage. lohnt sich natuerlich nicht wenn man schnell mal ein kleines spiel macht, aber jede engine die man kaufen kann hat all diese abstraktionslayer.
Ein Irrglaube, dem ich selber jahrelang nachgelaufen bin (ich habe mehrere solcher Layer geschrieben). Die UE3 hat Abstraktionslayer, ja, die haben auch Manpower, Zeit, und Geld um diesen Aufwand zu betreiben. Aber sonst? So gut wie alle PC-Kracher der letzten Jahre haben nur Direct3D verwendet. Von Valves Source-Engine ist bekannt, dass sie Direct3D ohne Layer verwenden. Quake 2/3/4? OpenGL. Chronicles Of Riddick, Doom 3? Am PC OpenGL, auf der Xbox Direct3D. Ja, klar, man kann die Dinge so coden, dass ein Codeersatz dann schnell machbar ist, aber von abstraktionen mittels Interfaceklassen kann man sich schnell verabschieden. (Siehe PS2-Beispiel.)
Ein Abstraktionslayer nach klassischem Stil mit abstrakten Basisklassen usw. bringt in Summe kaum was (und kostet ungemein viel Zeit). Wie behandelt man zB die sehr nützlichen OpenGL-RECT-Texturen, die es in D3D nicht gibt? Die Arbeit mit den Pixelformaten nicht vergessen. Die Orientierung (OpenGL bottom-up, D3D top-down - besonders lästig bei Render-to-Texture). GLSL ist anders aufgebaut als HLSL (Shaderlinken in dem Sinne gibts bei HLSL gar nich zB). OpenGL kennt diverse Extraformate wie zB RGBE9 (RGB with Exponent), SRGB-Texturen (obwohl, hat D3D die nicht auch?), Direct3D wiederum hat YUV-Texturen (die OpenGL nicht hat) Usw.
Am Ende hat man meistens ein Dings, das zwar läuft, aber entweder eine Schnittmenge von OGL- und D3D-Features ist, oder lauter kleine Eigenheiten hat. Wenn man nicht gerade Epic heisst, ist der Nutzen wirklich null, man hat nur sehr viel Extraarbeit (v.a. wegen Bugfixing und Testen). Dieser Layercode wird nämlich EBENFALLS gekapselt werden. Oder haut ihr die Statesets oder die Ressourcen (VB, IB, Texturen, Shader) überallhin im Code? Nein? Na bitte. Genausowenig würde man das tun, wenn man zB OpenGL direkt verwenden würde.
Was anderes ist zB ein OpenGL-Layer. Sowas habe ich jetzt, ein sehr dünner Layer, der auf die States aufpasst (damit man vor jedem Renderblock die Defaultstatesets voraussetzen kann), das Extensionladen, diverse Enumeration, Mipmapgeneriercode, Kapselung in Ressourcenklassen (V/P/FBO, 1/2/3D-Texturen, Cubemap, Texturarrays, Shader, Uniformbuffer) usw.
EDIT: Wirklich lustig sind die Engines, die Input- und Netzwerklibraries abstrahieren, die SELBER APIs abstrahieren. Im Übrigen, was willst du beim Filehandling abstrahieren? Bedenke, dass wir hier noch vom PC-Rahmen reden.
das ist natuerlich auch unfug. man kann ohne abtraktionslayer arbeiten wenn man eine applikation wirklich nur als fire&forget plant, aber meistens hat man einen wrapper. dass sowas sehr gut geht beweisen spiele die z.b. mit der renderware engine gemacht wurden und auf so ziemlich jedem system zu haben sind (siehe z.b. deren techdemo "burnout")
Dann sieh dir Renderware mal genauer an. Und bedenke, dass Engines bei kommerzielle Spieleprojekte NIE fixe vorgefertigte Blöcke sind, i.d.R. wird die dem Spiel angepaßt, Unnötiges rausgehaut usw. (letzteres ist auf der PS2 unbedingt notwendig.) Nicht selten kriegt man sogar nur im wesentlichen einen Repositoryzugang...
doch, macht man, wenn man einen saubere schnittstelle mittels wrapper hat. dann kann man d3d8/d3d9/d3d10/ogl/ps3/xbox umschalten wie es einem lustig ist. nicht so zu arbeiten ist wirtschaftliche dummheit. ein spiel zu entwickeln kostet immer mehr wegen dem content und der abstraktionslayer als grundlage sauberen programmierens kostet nur maintaining und im schlimmsten fall 3mann-monate an arbeit, kosten-nutzen ist erschlagend ueberzeugend.
Nette Philosophie. Es gibt nur einen gewichtigen Faktor, der DAGEGEN spricht: Zeit. Spieleentwicklung ist kein Ort für Leute, die unbedingt elegant coden wollen. Spiel X muss schnell raus sein, daher wird gehackt wie wild. Beispiele sind die Golgotha-Codebase, Alien vs Predator-Source, Freespace2-Source (der ist noch relativ human).
Zeit ist Geld. In der Spieleentwicklerbranche ist Geld ALLES. Wenn die Codebase funktioniert, wird sie genommen, Zeug wird dazugehackt bei Bedarf. Oft gibt es gar keine Zeit für ein Aufräumen. Natürlich ist eine gute Codebase Gold wert, aber sie von Anfang an durchzukonzipieren und dann jedes Mal warten ist für wenige eine Option.
am angenehmsten ist direkt auf hardware zu arbeiten, bzw seinen layer darum zu bauen;)
Naja. ehrlich gesagt vermisse ich das Rasterizerschreiben nicht sehr...
-
dv_ schrieb:
rapso schrieb:
das ist natuerlich kein unfug, jede gute engine hat einen abstraktionslayer fuer die graphik api, aber nicht nur dafuer, sondern ebenfalls fuer input, filehandling, netzwerk-lib, etc. das hat nichts mit treiberleistung zu tun, sondern mit sauberer programmierung und ist eine simple grundlage. lohnt sich natuerlich nicht wenn man schnell mal ein kleines spiel macht, aber jede engine die man kaufen kann hat all diese abstraktionslayer.
Ein Irrglaube, dem ich selber jahrelang nachgelaufen bin (ich habe mehrere solcher Layer geschrieben). Die UE3 hat Abstraktionslayer, ja, die haben auch Manpower, Zeit, und Geld um diesen Aufwand zu betreiben.
da verwechselst du vielleicht ursache und wirkung. sie sind wer sie sind eben weil sie gut programmieren. wenn du dir den UE3 source anschaust, siehst du komplexen und guten code, der seit der UE1 zum teil gewachsen ist. das war keine fire&forget mentalitaet.
Aber sonst? So gut wie alle PC-Kracher der letzten Jahre haben nur Direct3D verwendet. Von Valves Source-Engine ist bekannt, dass sie Direct3D ohne Layer verwenden. Quake 2/3/4? OpenGL. Chronicles Of Riddick, Doom 3? Am PC OpenGL, auf der Xbox Direct3D.
deswegen haben sie wohl die masse an licensies</ironie>
aber nein, dazu kann ich nichts sagen, ich kenne die sourcen von den neuen titeln nicht und weis deswegen nicht ob da eine saubere schnittstelle ist.Ja, klar, man kann die Dinge so coden, dass ein Codeersatz dann schnell machbar ist, aber von abstraktionen mittels Interfaceklassen kann man sich schnell verabschieden. (Siehe PS2-Beispiel.)
omg, du denkst allerernstes das man den ganzen code der z.b. auf d3d9 gegen z.b. ogl tauschen sollte statt einer sauberen schnittstelle und dann nur den layer drunter zu tauschen?... ich muss dich falsch verstanden haben.
Ein Abstraktionslayer nach klassischem Stil mit abstrakten Basisklassen usw. bringt in Summe kaum was (und kostet ungemein viel Zeit).
du vermischt design und implementierung.
Wie behandelt man zB die sehr nützlichen OpenGL-RECT-Texturen, die es in D3D nicht gibt?
vermutlich so wie es die leute schon machen.
Die Arbeit mit den Pixelformaten nicht vergessen. Die Orientierung (OpenGL bottom-up, D3D top-down - besonders lästig bei Render-to-Texture). GLSL ist anders aufgebaut als HLSL (Shaderlinken in dem Sinne gibts bei HLSL gar nich zB). OpenGL kennt diverse Extraformate wie zB RGBE9 (RGB with Exponent), SRGB-Texturen (obwohl, hat D3D die nicht auch?), Direct3D wiederum hat YUV-Texturen (die OpenGL nicht hat) Usw.
deswegen benutzten sogar die kleinsten spieleschmieden resourcecompiler die daten fuer die entsprechende plattform optimiert ablegen. pixelformate sind dabei nur ein kleiner faktor neben endianes, swizzling, allignment etc.
Am Ende hat man meistens ein Dings, das zwar läuft, aber entweder eine Schnittmenge von OGL- und D3D-Features ist, oder lauter kleine Eigenheiten hat. Wenn man nicht gerade Epic heisst, ist der Nutzen wirklich null, man hat nur sehr viel Extraarbeit (v.a. wegen Bugfixing und Testen).
der nutzen ist dass man ein spiel fuer pc und konsolen rausbringt. vielleicht 5% mehr entwicklungskosten und einen doppelt (oder manchmal 5mal, wenn man sich das ausland wie z.b. usa anschaut) groesseren markt hat.
Dieser Layercode wird nämlich EBENFALLS gekapselt werden. Oder haut ihr die Statesets oder die Ressourcen (VB, IB, Texturen, Shader) überallhin im Code? Nein? Na bitte. Genausowenig würde man das tun, wenn man zB OpenGL direkt verwenden würde.
super, dann weisst du ja was eine schnittstelle ausmacht.
das impliziert nicht einfach nur abstrakte klassen. es ist ein designpattern und kann auf vielen wegen implementiert werden.Was anderes ist zB ein OpenGL-Layer. Sowas habe ich jetzt, ein sehr dünner Layer, der auf die States aufpasst (damit man vor jedem Renderblock die Defaultstatesets voraussetzen kann), das Extensionladen, diverse Enumeration, Mipmapgeneriercode, Kapselung in Ressourcenklassen (V/P/FBO, 1/2/3D-Texturen, Cubemap, Texturarrays, Shader, Uniformbuffer) usw.
layer, block, wrapper, interface, schnittstelle... wie man es auch nennt, es kapselt die API vor direkten zugriffen, simple OOP grundlage.
EDIT: Wirklich lustig sind die Engines, die Input- und Netzwerklibraries abstrahieren, die SELBER APIs abstrahieren. Im Übrigen, was willst du beim Filehandling abstrahieren? Bedenke, dass wir hier noch vom PC-Rahmen reden.
was du als lustig betitelst ist eine saubere schnittstelle. denn d3d9 und ogl sind selbst auch abstrahierende librarys und die werden von den engines auch gekapselt.
beim filehandling abstrahiert man files, was sonst? so kannst du von der festplatte, aus archives, per netzwerk oder nur memory-files verarbeiten. dabei simple streams, memorymapped oder compressed files nutzen ohne davon zu wissen, geschweige denn von anfang an schon alles fertig implementiert zu haben... natuerlich nicht zu vergessen platform spezifische apis.
es wird ja kaum jemand fopen in seinem produkt nutzen*hehe*.das ist natuerlich auch unfug. man kann ohne abtraktionslayer arbeiten wenn man eine applikation wirklich nur als fire&forget plant, aber meistens hat man einen wrapper. dass sowas sehr gut geht beweisen spiele die z.b. mit der renderware engine gemacht wurden und auf so ziemlich jedem system zu haben sind (siehe z.b. deren techdemo "burnout")
Dann sieh dir Renderware mal genauer an. Und bedenke, dass Engines bei kommerzielle Spieleprojekte NIE fixe vorgefertigte Blöcke sind, i.d.R. wird die dem Spiel angepaßt, Unnötiges rausgehaut usw. (letzteres ist auf der PS2 unbedingt notwendig.) Nicht selten kriegt man sogar nur im wesentlichen einen Repositoryzugang...
ja und je besser die schnittstelle zwischen den bloecken, desto einfacher kann man sie entfernen/einfuegen/austauschen. deswegen hat man eben die schnittstellen/abstraktionslayer.
doch, macht man, wenn man einen saubere schnittstelle mittels wrapper hat. dann kann man d3d8/d3d9/d3d10/ogl/ps3/xbox umschalten wie es einem lustig ist. nicht so zu arbeiten ist wirtschaftliche dummheit. ein spiel zu entwickeln kostet immer mehr wegen dem content und der abstraktionslayer als grundlage sauberen programmierens kostet nur maintaining und im schlimmsten fall 3mann-monate an arbeit, kosten-nutzen ist erschlagend ueberzeugend.
Nette Philosophie. Es gibt nur einen gewichtigen Faktor, der DAGEGEN spricht: Zeit. Spieleentwicklung ist kein Ort für Leute, die unbedingt elegant coden wollen. Spiel X muss schnell raus sein, daher wird gehackt wie wild. Beispiele sind die Golgotha-Codebase, Alien vs Predator-Source, Freespace2-Source (der ist noch relativ human).
jap, die philosophie wird von firmen wie EA, Ubisoft, Epic, Crytek, usw. befolgt, weil das der schluessel zum erfolg ist. natuerlich gibt es unmengen von firmen mit diesre fire&forget mentalitaet die manchmal nur ein jahr und manchmal 20jahre lang auf dem selben niedrigen niveau um ihr ueberleben kaempfen... wieso nur
... sogar ID-software schwaechelt, weil kaum noch jemand ihre engine lizensiert, weil die leute die sich durch schlechten code kaempfen einfach nur um "dabei zu sein" so langsam ausgehen und man ueberall lieber sehr viel mehr investiert, dafuer aber zukunftssicher und nicht nur bis zum release des aktuellen titels plannen kann und danach schaut man mal ob es top oder flop is und macht dann das selbe nochmals. Es braucht nur simplen menschenverstand um zu sehen dass dieses glueckspiel am ende in den meisten faellen schlecht endet.Zeit ist Geld. In der Spieleentwicklerbranche ist Geld ALLES. Wenn die Codebase funktioniert, wird sie genommen, Zeug wird dazugehackt bei Bedarf. Oft gibt es gar keine Zeit für ein Aufräumen. Natürlich ist eine gute Codebase Gold wert, aber sie von Anfang an durchzukonzipieren und dann jedes Mal warten ist für wenige eine Option.
wuerde man teufelskreis nennen. Zeit ist geld und hacks kosten am ende viel zeit -> geld, nicht nur durch die fehler die sie verursachen, die seiteneffekte schwer zu beheben sind und sie die qualitaet des produktes limitieren, sondern auch weil so ein code nicht reused werden kann (wer will/kann schon mit nem code voller hacks arbeiten?), weil nur der maintainer die hacks wirklich kennt und je groesser ein team ist, desto groesser der daraus enstehende verschleiss, ganz zu schweigen von der abhaengigkeit einer firma von speziellen personen.
Desginpattern gibt es nicht dafuer weil sich jemand dachte "eventuell langweilt sich mal jemand und hat dann lust ein paar hacks durch verlaesslichen und guten code auszutauschen", sondern um von anfang an guten code zu schreiben. aus diesem grund nutzen auch viele firmen 3rd-party libs, weil man verlaesslichen code will. und selbst wenn man 500k fuer ne UE3 license zahlt, wo irgend ein hobby coder meint man muesse nur mal eben nen 3ds-loader schreiben, ein paar md2 objekte rumlaufen lassen und fertig ist das spiel. darauf laesst sich kein management ein wenn die firma in 2titeln noch existieren soll.
-"fix ich wenn ich am ende zeit habe"
-"machen wir naechstes mal besser"
-"schreib ich from scratch neu und besser"
indizien dafuer dass ein projekt falsch laeuft.-"code-lock bis alles stabil ist"
-"ab alphadate keine neuen features"
-"ab beta featurecomplete und nur noch fixes"
-"sauberes design ist wichtig, keine hacks!"
indizien dafuer dass ein projekt gut laeuft.falls man sich mal bei einer firma bewirbt, sollte man einfach mal fragen wie sowas ablaeuft, dann weiss man unter welchen bedingungen man arbeiten wird. wie gestresst die arbeitskolegen sein werden. wie knapp sich die firma ueber wasser halten wird.
