Niemand braucht OpenGL Programmierer!
-
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.
-
rapso schrieb:
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.
Sie sind wer sie sind weil u.a. die Unreal-Linie sich verkauft hat wie warme Semmeln. Die UE hat ein gutes Design, das stimmt. Der Abstraktionslayer stammt aber aus Unreal1-Zeiten, damals war es unbedingt notwendig. Den jetzt zu ersetzen wäre ein ziemlicher Wahnsinn. Im Übrigen ist Epic neben id eines der wenigen Studios, die es sich leisten können, Zeit in eleganten Code zu stecken. Wie bereits gesagt: die meisten haben diesen Luxus nicht.
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.Das Doom3 SDK ist sehr sauber programmiert. Das Valve-SDK ist ein Sauhaufen, und wenn die Gerüchte um den Code stimmen, ist die Engine nicht viel besser.
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 mit abstrakten Basisklassen, virtuellen Methoden usw. kannst du bei Konsolen vergessen. Virtuelle Funktionen selbst kannst du meistens vergessen. Besonders hart ist das bei der PS2. Wo es halbwegs geht ist die Xbox, die ist aber eigentlich ein halber PC
Ein Abstraktionslayer nach klassischem Stil mit abstrakten Basisklassen usw. bringt in Summe kaum was (und kostet ungemein viel Zeit).
du vermischt design und implementierung.
Nein. Ein umfassender Abstraktionslayer *ist* viel Arbeit. Wie bereits gesagt, muss man sämtliche Pixelformate abstrahieren, die Enumerierung, Ressourcen, usw. Ausser du willst nur wenig Funktionalität, zB dass dir egal ist, welches Pixelformat ne RGB-Textur hat. Aber umfassend.... XEngine ist genau sowas, es ist eine Low-Level Engine, die sich voll und ganz auf den Abstraktionslayer konzentriert. Sieh dir an, wie lange schon daran entwickelt wird, und wie groß sie ist.
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.
Uff. Tolle Antwort. Wie wärs mit "unsauber" oder "gar nicht"? Entweder man checkt in darüberliegenden Schichten, ob der Backend RECT-Texturen hat, dann aber ist der Sinn der Abstraktion irgendwie weg. Oder man lässt sie weg -> Schnittmenge der API-Features.
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.
Siehe oben. Ausserdem ist es mit einem Ressourcencompiler nicht getan. Wie willst du mit einem Ressourcencompiler das Orientierungsproblem angehen? Das RECT-Problem? Usw.
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.
5% ändern von PC zu PS2? Oder gar PC -> PS3? Träum weiter. Umgekehrt ginge das eher (naja, PS3->PC wohl auch nicht). Die echten Kracher kann nicht "mal eben" portieren. Bitte stell dir sowas wie Shadow Of The Colossus vor. 5%? Für dieses Spiel haben sie das allerletzte aus der PS2 rausgeholt, plattformunabhängigen Code kannst du da wirklich vergessen.
Für technisch anspruchsloseres Zeug ists natürlich anders.
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.[/quote]layer, block, wrapper, interface, schnittstelle... wie man es auch nennt, es kapselt die API vor direkten zugriffen, simple OOP grundlage.
Das Kapseln der API hat den theoretischen Grund, dass man so Vermischungen der Applikationsschichten vermeidet. Allerdings gibt es keinen Unterschied, ob ich glBlendFunc(GL_ONE, GL_ONE) oder rasterizer.blending(One, One) aufrufe. Die Kapselung geschieht auf höherem Level. Z.B. nurbs.render(camera, time). Eine 1:1 Kapselung (also sowas wie rasterizer.blending()) macht nur Sinn, wenn ich zB die States cachen will, um redundante Aufrufe zu vermeiden (oder um die States zum Defaultwert zurückzusetzen).
Wobei: reden wir vom selben Konzept? Ich kritisiere 1:1 Abstraktionen, keine stärkeren (wie eben "gib mir einfach nur ne RGB-Textur").
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*.Du hast mich einfach nicht verstanden. Es ist SINNLOS, ein Abstraktionslayer nochmal zu abstrahieren, wenn keine echte Funktionalität dadurch dazukommt. Wenn Library X bereits darunterliegende Socketlibraries abstrahiert, wieso soll ich X abstrahieren? Mir fallen nur zwei Gründe ein: lizenzrechtliche Gründe, um X im Härtefall auszutauschen, und sprachliche Gründe (zB FMOD-Aufrufe in Klassen packen, um von RAII usw. nutzen zu machen). Sonst gibt es technisch gesehen genau null Nutzen, X zu abstrahieren.
Deine Fileabstrahierun nennt man übrigens "virtual file system". Und fopen *wird* verwendet, vor allem bei Videos (und manchmal bei Musikstücken).
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.
Wie schon x-mal gesagt: dieses "Umschalten" kannst du v.a. bei AAA-Titeln vergessen (dass du allen Ernstes denkst, man kann einfach so zur ps3 umschalten, ist wirklich amüsant). Man muss nicht alles neu Coden, das ist klar. Aber das "einfache Austauschen" ist ein Märchen.
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.Willkommen in der Realität. Hier haben Spielefirmen i.A. keine Zeit, und ein einziger Flop reicht aus, um die Firma zu killen. Ausnahmen sind Epic, Crytek, Ubisoft, EA, id, Blizzard, Valve, die haben auch die nötige Kohle. Aber die Regel lautet: das Spiel muss so schnell wie möglich raus. Wieso glaubst du sind bugverseuchte Spiele mittlerweile die Regel?
"Investieren". "Zukunftssicher". Herrje, du hast ein total verdrehtes Bild von der Spieleentwicklung. Zukunftssicher ist sie absolut nicht. Sicherheit gibts insgesamt nicht in dieser Branche - es IST ein Roulette (ausser bei den Großen; Blizzard hat mit WoW, Diabo, und Starcraft eine ziemlich gute Sicherheit
). Im Übrigen ist der Grund für id's Doom3-Engine-Schwächeln nicht der Code (der ist exzellent), sondern ganz einfach dass sie nicht mehr die einzigen mit Der Ausnahmeengine (tm) sind, wie du richtig sagst Content immer wichtiger wird, und sie so richtig nur für dunkle Szenarien taugt (hat mit der Rendertechnik zu tun).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.
Genauso ist das. Sieh dir den Alltag von EA-Programmierern an. Verschleiß ist ein großes Problem bei Spieleentwicklern. In der Branche bleibt man üblicherweise nicht so lang.
Und, man muss sehr wohl mit den Hacks klarkommen.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.
Ich weiss was design patterns sind. Danke.
aus diesem grund nutzen auch viele firmen 3rd-party libs, weil man verlaesslichen code will.
Nein. Man kriegt eben keine fix-und-fertig Engine, sondern einfach nur Zugang zu ihr (zB die Dark Engine wurde parallel zu System Shock 2 entwickelt, das diese Engine verwendet hat; ähnlich mit der Source Engine bei Vampire Bloodlines). Der wahre Nutzen der UE3 ist die Toolchain. Die Engine selbst ist sehr gut, ja, aber die Toolchain ist Gold wert. Daher hier ein Appell an alle Hobby-Engine-Coder: die Toolchain ist ALLES. ALLES. Schreibt eine exzellente für eure Engines, wenn sie was wert sein sollen.
-"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.Alltag in der Spieleentwicklerbranche. Ausser der Teil mit from Scratch. Passiert, aber nicht oft. Die "fixes die ich am ende mache" erscheinen üblicherweise als Patch.
-"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.Publisher sagt sehr bald ciao.
Das wäre übrigens beinahe mit den Unreal-Entwicklern passiert. Unreal hat sich so lange verzögert, die Geldgeber wurden ungeduldig.
-
Warum hab ich das Gefühl, dass ungeduldige Geldgeber und dreckige Hacks einen großen Anteil daran haben, dass die Qualität von Spielen jährlich neue Tiefstmarken erreicht?
"Ja, kommt, rotzt mal kurz was raus, sollte doch nicht lange dauern. Ist auch egal wenn wir nachher ein paar Patches raushauen müssen, die Animationen unrund wirken, der Sound stottert, die Texturen zu schlampig sind und die Story keine Rede wert ist, Hauptsache, wir sind vor der Konkurrenz fertig."
Kurzsichtig machbar, aber langfristig?
Heutzutage packe ich gerne mal wieder uralte Titel aus, die aber dafür genial gemacht waren. Diablo I, Fallout (obwohl man da zugeben muss, das war auch ziemlich buggy. Aber vom Design her unglaublich gut!), Eye of the Beholder (wer's noch kennt). Das sind Spiele, die werd ich auch in 10 Jahren nochmal auspacken. Und wenn ich extra dafür meinen P2 behalten muss. Dagegen hab ich die Titel von letztem Jahr schon wieder vergessen. Und von vielen Leuten weiß ich, dass es ihnen ähnlich geht.
Merkt man was? Dreckiges Hacks und halbgares Contentdesign sind zwar die Zukunft, aber nicht zukunftsfähig.
Aber wir leben ja sowieso in einer Ex-und-Hopp-Welt, Hauptsache verkauft, egal, was danach damit passiert.
gruß
Martin
