Niemand braucht OpenGL Programmierer!

[inp]

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.

[dv_]

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/

[rapso]

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;)

[hustbaer]

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.

[dv_]

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...

[rapso]

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.

[dv_]

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.

[mad_martin]

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

[dv_]

Die Gamedev-Branche ist seit Jahren in einer Krise, das stimmt. Entwicklungen kosten einfach zuviel, müssen in zu kurzer Zeit fertig sein, und müssen sich rentieren (da brech ich auch ne Lanze für die kleinen Entwicklerstudios, die können sich Flops einfach nicht leisten, die rotzen das also nicht aus Gier aus).

Vor, sagen wir, 10-15 Jahren wäre ich gerne Spieleentwickler gewesen. Heute nicht mehr. Vielleicht wird der neue Trend zu Casual Games dem Fluch ein Ende bereiten.

[mad_martin]

Kleine Studios geben sich m.M.n. aber mehr Mühe, weil deren Überleben meiner Einschätzung nach eher von der Qualität des Titels als von seinem Fertigstellungstermin abhängt. Einmal scheiß Qualität auf den Markt geworfen, dann ist's dann auch vorbei. Und wenn das dann daran hängt, dass jemand irgendwo oben, wo die Deadline entschieden wird, den geistigen Totalaussetzer hatte, dann ist das echt schade.

Glück haben die großen, die vor Jahren ihren Grundstein gelegt haben. Bestes Beispiel dafür: Blizzard mit der Warcraft-Reihe und dem Ableger Starcraft. Da hat sich schnell eine große Fangemeinde gebildet, für die produziert werden konnte. Sich heute zu etablieren ist viel schwerer geworden, allein durch die dicke Konkurrenz. Wer jetzt in diesem Augenblick ein RTS entwickelt, weiß, dass er gegen Starcraft 2 antreten darf. Egal, wie das Spiel entgültig ist (der erste Trailer war vielversprechend ), mit den zu erwartenden Verkaufszahlen muss man erstmal mithalten können. Das man da zu früh fertig macht, um die Zeit vor der Konkurrenz zu nutzen, liegt nahe. Kaum einer ist mutig genug und versucht, die Qualität des eigenen Titels zu sichern, um dann nach der ersten Starcraft2-Begeisterung den Markt zu übernehmen.
Klar, die Meßlatte wird hoch sein, aber wenn man dagegen etwas halbgares auf den Markt wirft, kann man nicht damit rechnen, vor der Konkurrenz alles abzusahnen bzw. auch nur Gewinn zu machen.

Früher war alles besser
Als es noch Black Isle gab. Auch wieder ein Beispiel für ein Superteam, das vom Publisher kaputt gemacht wurde...

[dv_]

Black Isle-Spiele haben sich einfach nicht gut verkauft, obwohl sie exzellent waren. Gegen Counterstrike, Quake X usw. ist eben schwer anzukämpfen ..

Aber das mit den Releaseterminen ist wahr. Gutes Beispiel ist System Shock. An sich ein geniales Spiel, aber als es 1994 erschien, hat jeder Doom 2 und Descent gespielt. Dann, System Shock 2 erscheint, und muss gegen Half-Life antreten...

[rapso]

dv_ schrieb:

Sie sind wer sie sind weil u.a. die Unreal-Linie sich verkauft hat wie warme Semmeln.

weil sie investoren hatten die ihnen das geld und somit die zeit gaben so ein gutes spiel zu machen, vermutlich weil es eben gut lief und der code gut war.

Die UE hat ein gutes Design, das stimmt. Der Abstraktionslayer stammt aber aus Unreal1-Zeiten, damals war es unbedingt notwendig.

nein, es war nicht unbedingt notwendig, den das spiel kamm raus als es kaum beschleuniger gab bzw. die die es gab waren nicht schneller als software, deswegen kam erst spaeter ein patch fuer 3dfx, davor war es rein software und haette somit keine zwischenschicht benoetgit.

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.

wie schon bereits x-mal gesagt, das ist kein luxus, sondern eine investition in die zukunft, wenn man sich die zeit nicht nimmt, wird man nie zeit haben, weil man im nachhinein fuer seine "jugendsuenden" doppelt zahlt.

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.

naja, bisher war der id-source immer sehr..emm.. funktional und deswegen extrapolier ich mal dass es bie D3 weit so ist, da carmack wohl nicht ploetzlich alle c++ pattern befolgt usw.
den SE source hab ich noch nicht, somit kein kommentar.

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

wie schon gesagt, du verwechselst implementation und design, aber das ist ja auch der unterschied zwischen coder und programmierer
hier eine andere von vieeeln moeglichkeiten ein interface zu deklarieren

template<class T>
class CTexture
{
.
.
.
};

#if defined(PS3)
typedef CTexture<CTextureOgl> tdTexture;
#elif defined(XBOX)
typedef CTexture<CTextureD3D> tdTexture;
#else
STATIC_ASSERT("Not implemented")
#endif

ohne einen einzigen virtuellen aufruf... wie gesagt, ein weg von vielen.

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.

jup schon krass, 5jahre und mehr als ein kleiner shaderviewer scheint es nicht zu sein. da hab ich schon sehr viel bessere engines inkuerzerer zeit entstehen sehen, siehe nebula device (2).

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.

oder man emuliert auf den fehlenden systemen diese funktionalitaet falls sie wirklich notwendig ist, oder ... auf jedenfall besser als am ende doch auf eine andere plattform portieren zu muessen und zu merken dass 100dinge garnicht exisiteren und man diese tollen ..emm... "hacks" einbauen muss.

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.

das waere bloedsinnig ein orientierungsproblem im resourcecompiler anzugehen.

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.

was glaubst du wie gross das team war, wieviel kosten das spiel verursacht hat? die kosten fuer ein oder zwei personen die das auf dem pc waehrend der ganzen entwicklung am laufen halten sind dagegen laecherlich wenig. ein sauberer wrapper der schnittstellen hindert dabei kaum ein performantes arbeiten. die derzeitigen spiele werden auch fuer d3d9 und d3d10 mittels wrapper lauffaehig gemacht und es ist wohl kaum der fall, dass eines davon grausam langsam laeuft. was zudem impliziert dass so ziemlich jeder programmierer mit weitsicht zZ nen sauberen layer nutzt um einfach zwischen den beiden APIs mappen zu koennen. und da gibt es weit groessere unterschiede als nur dein so geliebtes RECT

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.

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).

die kapselung passiert meist an einer stelle die oft verwendet wird, aber nur einmal vorhanden ist. so gibt es z.b. keinen GL_ONE, sondern den gewuenschten state den man dem renderer uebergibt z.b. Renderer.BlendMode(BLEND_ADDITIV). und dieser macht dann das neotige. das impliziert, dass man keine D3D... oder GL... ausserhalb dieses codes hat. intern bei Brush.Render, Nurbs.Render, Split.Render, Font.Render etc. den code umzuschreiben ist natuerlich redundante arbeit und dann ist das auch fehleranfaellig und schlechter wartbar. wuerde wohl kaum jemand machen.

Wobei: reden wir vom selben Konzept? Ich kritisiere 1:1 Abstraktionen, keine stärkeren (wie eben "gib mir einfach nur ne RGB-Textur").

wir reden von einer abstraktion wie man sich die wuenscht. das kann von person zu person (oder team zu team) anders sein.
Ein graphiker erstellt eine textur, speichert sie mit den empfohlenen einstellungen fuer die jeweilige plattform (z.b. 16color, oder dxt). der resourcecompiler erstellt dann die texturen mit den formaten die fuer die jeweilige plattform moeglich sind. der renderer bekommt dann immer die richtigen daten als resource. die formate die man selbst im code braucht z.b. font. muss man entsprechend auf jeder plattform supporten, notfalls emulieren.
ich weiss nicht ob das ein 1:1 mapping wie du es meinst. (1:1 klingt nicht moeglich wenn man sich mal ein paar mehr plattformen anschaut als PC).

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.

der sinn ist der, dass man darauf aufbaut. eventuell die naechsten 10jahre lang. du kannst nicht fuer 10jahre vorhersehen, ob du diese lib verwenden wirst. alleine schon deswegen hast du einen wrapper, darauf baust du nun dein riesiges softwaregebilde auf, statt direkt irgendwelche z.b. fmod funktionen aufzurufen. in 5jahren, wenn du ne riesen lib hast, tauscht du einfach nur den wrapper aus fuer die BassLib, statt fmod und musst nicht an tausenden stellen fmod-eigenheiten auf BassLib mappen.

Deine Fileabstrahierun nennt man übrigens "virtual file system". Und fopen *wird* verwendet, vor allem bei Videos (und manchmal bei Musikstücken).

ach du weisst wie man es nennent, wozu fragst du dann so als ob du keinen plan haettest?
gerade bei streaming verwendet man eher kein fopen das noch OS spezifisches caching hat, sondern meist memorymapping.

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.

komisch, kenne AAA-titel bei denen das einfach so auf PS3 geht, was laeuft da falsch?

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?

weil viele glauben dass sie mit ihrem hobbyprogrammierer-niveau heute noch spiele programmieren koennen. weshalb glaubst du haben firmen wie Epic,Crytek,etc. keine flops (was softwarequalitaet angeht)? deren software ist zich mal komplexer als das was diese 08/15 spiele leisten koennen die bugverseucht sind. soviel mal mehr leute haben sie aber nicht, wie kann es dann sein, dass deren software sauber ist?

"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 ).

aber auch die grossen backen nur mit wasser ;). und waehrend kleine firmen irgendwelchen misst rauswerfen koennen, muessen die grossen ihre zig millionen an investitionen einfahren. kann/will sich niemand leisten und deswegen macht man es gleich richtig. Das trifft nicht nur auf grosse firmen zu. kleinere entwickler koennen ebenfalls sehr gute spiele entwickeln, es ist nicht nur eine sache des geldes. ich hab schon an kleineren entwicklungen mitgearbeitet bei der am ende ein sauber programmiert produkt entstand das ohne patch reibungslos lief und nicht nur gerade so die entwicklungskosten einbrachte. Zu behaupten kleine dinge waeren ohne hacks nicht moeglich ist schlichtweg falsch, auch dass die nur ein roulette waeren. jedes kleine projekt kann sauber ohne hacks ablaufen. und riesige projekte wie z.b. die harz4 software kann trotz unsummen und riesigen teams total verkackt werden.

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.

Du kennst scheinbar nur die die ihrem mittelpunkts-drang nachgehen, ich kenne viele bei EA/MS/Ubisoft z.b. einige bei Rare die ihre arbeit moegen und seit jahrzehnten dabei sind.

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.

durchbrich die kluft zwischen wissen und verstehen

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.

ja, was die tool-quality fuer die entwicklung ist, sind die pattern fuer guten code. man kann natuerlich hacks coden, oder textdateien als "tools" nutzen, aber wie du schon sagst. ALLES...
tools ist nur ein weiterer schritt im sauberem entwickeln und programmieren. und du kannst auch tools so bauen dass sie trotz hacks gut laufen, dass man z.b. kein leerzeichen in einem dateinamen haben darf damit speichern funktioniert bei einer level ohne den fehler anzuzeigen. und klar kann man sich dann "wichtigerem" witmen was es zu programmieren gibt. was diese 10min dann an stunden an mehrarbeit akkumulieren bei denen die das tool nutzen und ihre zeit bei ihren wichtigen dingen fehlt ist dann nur ein resultat von hacks.

-"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.

oder garnicht...

-"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.

jap, es war schon sehr strapazioes was epic mit den publishern machte, aber wie du siehst, es hat sich ausgezahlt nicht einfach nur das spiel auf den markt zu werfen wenn der publisher zum ersten mal jault. war bei crytek und vielen anderen wohl nicht anders.

[rapso]

mad_martin schrieb:

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?

das ekleart auch weshalb spieleprogrammierer soeinen abwertigen ruf haben unter informatikern. andere muessen groessere und nicht minderkomplexe dinge programmieren und bekommen es hin, trotz negativbeispiele wie eben hartz4-software.

[dv_]

naja, bisher war der id-source immer sehr..emm.. funktional und deswegen extrapolier ich mal dass es bie D3 weit so ist, da carmack wohl nicht ploetzlich alle c++ pattern befolgt usw.
den SE source hab ich noch nicht, somit kein kommentar.

Carmack verwendet C++ in Doom3, wenn auch eher konservativ. Aber sauberer als Quake3 scheint es allemal zu sein.

wie schon gesagt, du verwechselst implementation und design, aber das ist ja auch der unterschied zwischen coder und programmierer

Ich rede nicht vom abstrakten Konzept, sondern von der 08/15-Hobbyengine-Realisierung, vor der ich hier die ganze Zeit warne. Aber, lass dich nicht stören, komm dir weiter toll vor. (Sorry, Statements wie "der unterschied zwischen coder und programmierer" klingen wie die von versnobten Erstsemestlern.)

jup schon krass, 5jahre und mehr als ein kleiner shaderviewer scheint es nicht zu sein. da hab ich schon sehr viel bessere engines inkuerzerer zeit entstehen sehen, siehe nebula device (2).

Genau. Die haben nicht die Zeit mit 1:1 (oder fast-1:1)-Abstraktion von Lowlevel-APIs vergeudet.

was glaubst du wie gross das team war, wieviel kosten das spiel verursacht hat? die kosten fuer ein oder zwei personen die das auf dem pc waehrend der ganzen entwicklung am laufen halten sind dagegen laecherlich wenig. ein sauberer wrapper der schnittstellen hindert dabei kaum ein performantes arbeiten. die derzeitigen spiele werden auch fuer d3d9 und d3d10 mittels wrapper lauffaehig gemacht und es ist wohl kaum der fall, dass eines davon grausam langsam laeuft. was zudem impliziert dass so ziemlich jeder programmierer mit weitsicht zZ nen sauberen layer nutzt um einfach zwischen den beiden APIs mappen zu koennen. und da gibt es weit groessere unterschiede als nur dein so geliebtes RECT

Mein Punkt ist, dass z.B. die PS2 und der PC zwei Plattformen sind, die sich sehr sehr stark unterscheiden. Je größer die Differenzen, desto größer der Aufwand. D3D9<->D3D10: ebenfalls große Unterscheide (wenn auch nicht so stark wie PS2<->PC, aber zB die Zusammenfassung zu State Groups, der Wegfall der FFP-Funktionalität, und die Einführung generischer Buffer sind schon krasse Unterschiede, und das ist lang nicht alles). Eine einheitliche Lowlevel-Schicht bringt da m.E. kaum was (mit lowlevel meine ich 1:1). Mehr dazu unten.

der sinn ist der, dass man darauf aufbaut. eventuell die naechsten 10jahre lang. du kannst nicht fuer 10jahre vorhersehen, ob du diese lib verwenden wirst. alleine schon deswegen hast du einen wrapper, darauf baust du nun dein riesiges softwaregebilde auf, statt direkt irgendwelche z.b. fmod funktionen aufzurufen. in 5jahren, wenn du ne riesen lib hast, tauscht du einfach nur den wrapper aus fuer die BassLib, statt fmod und musst nicht an tausenden stellen fmod-eigenheiten auf BassLib mappen.

Ok, das ist Grund 3, den ich vergessen hab: unsichere Abhängigkeiten. Wenn ich ne Opensource-Lib hab wie zB zlib, ist das kein Thema - das schmeiß ich in meine Codebase, und es bleibt dort sicher. Bei FMOD ist es eben *nicht* sicher: was, wenn der Laden morgen weg ist? Oder, wenn sich die Lizenzbedingungen ändern? Support weg ist? Usw. Da seh ich ne Extraabstraktion ein.

ach du weisst wie man es nennent, wozu fragst du dann so als ob du keinen plan haettest?

Ein VFS kenne ich eben als VFS. Fileabstrahierung klang komisch, ein VFS ist eher eine Filesystemabstrahierung

gerade bei streaming verwendet man eher kein fopen das noch OS spezifisches caching hat, sondern meist memorymapping.

Was nichts daran ändert, dass die Files dann frei herumliegen, in keinem Archiv oder sonstwas stecken, und nicht durchs VFS geroutet werden (also, bei einem ausgefeilten VFS vielleicht schon, aber die meisten "VFS" sind nicht mehr als Doom-WAD-style Listen). Aber mmap() ist da eigtl. überflüssig und stellenweise sogar schlecht, weil speziell bei Videos fürs korrekte A/V Sync der Playercode eine gewisse Menge an Frames im Vorhinein ladet.

komisch, kenne AAA-titel bei denen das einfach so auf PS3 geht, was laeuft da falsch?

Gib mir konkrete Titel.

weil viele glauben dass sie mit ihrem hobbyprogrammierer-niveau heute noch spiele programmieren koennen. weshalb glaubst du haben firmen wie Epic,Crytek,etc. keine flops (was softwarequalitaet angeht)? deren software ist zich mal komplexer als das was diese 08/15 spiele leisten koennen die bugverseucht sind. soviel mal mehr leute haben sie aber nicht, wie kann es dann sein, dass deren software sauber ist?

Hmm. Wiegesagt, Valve hat keinen sauberen Code Es ist natürlich schon eine Tendenz zu sauberen Code zu sehen, aber ich denke du irrst, wenn du das Problem an den Programmieren festnagelst. Schlimmer scheint mir das Projektmanagement zu sein, welches sehr oft das Team überschätzt und/oder falsch einsetzt.

aber auch die grossen backen nur mit wasser ;). und waehrend kleine firmen irgendwelchen misst rauswerfen koennen, muessen die grossen ihre zig millionen an investitionen einfahren. kann/will sich niemand leisten und deswegen macht man es gleich richtig. Das trifft nicht nur auf grosse firmen zu. kleinere entwickler koennen ebenfalls sehr gute spiele entwickeln, es ist nicht nur eine sache des geldes. ich hab schon an kleineren entwicklungen mitgearbeitet bei der am ende ein sauber programmiert produkt entstand das ohne patch reibungslos lief und nicht nur gerade so die entwicklungskosten einbrachte. Zu behaupten kleine dinge waeren ohne hacks nicht moeglich ist schlichtweg falsch, auch dass die nur ein roulette waeren. jedes kleine projekt kann sauber ohne hacks ablaufen. und riesige projekte wie z.b. die harz4 software kann trotz unsummen und riesigen teams total verkackt werden.

Natürlich, nur: waren es AAA-Titel? War dahinter ein Publisher, der die Arbeit von 8 Monaten in 3 haben will?
Man kann mit der falschen Publisherwahl einen bösen Fehler machen, zusammen mit Selbstüberschätzung und (manchmal selbst verschuldeter, manchmal vom Publisher hervorgerufener) Hypedruck kommt was unausgegorenes raus. Beispiel: Gothic 3.

Du kennst scheinbar nur die die ihrem mittelpunkts-drang nachgehen, ich kenne viele bei EA/MS/Ubisoft z.b. einige bei Rare die ihre arbeit moegen und seit jahrzehnten dabei sind.

Sind sie direkt bei diesen Firmen beschäftigt, oder bei einigen ihrer Studios? EA ist berüchtigt für deren Praktiken. 60-Stunden-Woche absolute Normalität, mit Versprechungen auf Auszahlung der Überstunden usw. EA Deutschland ist da vermutlich anders, aber EA US...

So. Und jetzt zur Erklärung der Abstraktion:

was ich als schlecht ansehe sind eben Versuche des 1:1 Mappings. Leider tendieren viele Hobbyengines dazu, eben sowas zu haben. Eben sowas wie Renderer::blending(one, one). Meistens ist es eigentlich nur eine Kopie der Direct3D-API, und genau sowas sehe ich nicht ein; es ist auch nicht leicht, in so einem Ding dann D3D und OGL zu vereinheitlichen. Es macht auch keinen Sinn, weil wie du schon gesagt hast D3D und OGL nur zwei APIs für dasselbe Backend sind, man hat also mit so einem Konstrukt eine Art Sternarchitektur (Hardware -> D3D, OGL -> Abstraktionslayer). So kann man keinen Nutzen aus den API-Eigenheiten ziehen, ein 1:1 Layer setzt einfach zu tief an.

Was anderes sind Abstraktionen auf höherem Level. Eine Komponente 2DElements, die 2D-Sachen rendert, und die zB vom Fontrenderer und der GUI verwendet wird. (Hier könnte ich die von dir verhasste RECT-Textur wunderbar im OpenGL-Backend reinbringen, ohne Hacks ) Eine Komponente Staticmesh, die die Vertexdaten als amorphen Datenstream akzeptiert (d.h. da gibt es keine Abstraktion von Vertexformaten, sondern direkte plattformspezifische Vertexdaten). Sowas in der Art stelle ich mir vor. (Von Spiel zu Spiel wird es ein paar Komponenten geben, die Fire&Forget sind, weil sie eben spielspezifisch sind, das ist unvermeidbar.) Stattdessen sehe ich oft Vertexbufferklassen, Rendererklassen mit drawPrimitive()-Methoden, usw. und genau das ist eine Sackgasse - weil es in Wirklichkeit nichts richtig kapselt, sondern den APIs nur ne andere Farbe drauflackiert. Früher sinnvoll, jetzt ... nicht mehr.

Verstehst du jetzt was ich meine? :p

Genau so bau ich ja meine Sachen bei Bedarf. Manches baue ich direkt mit OpenGL. Aber anderes plane ich in der Art, u.a. um später Nutzen aus OpenGL Longs Peak zu ziehen, dessen Aufbau deutlich vom jetzigen OpenGL abweicht. Und vielleicht, wenn ich eines Tages Vista installiere (oder D3D10 für XP kommt), noch ein D3D10-Backend. Aufwand: relativ gering.

Im Übrigen verstehe ich design Patterns, am PC programmiere ich laufend mit generischen, funktionalen, objektorientierten Konzepten, verwende den Preprocessor fast nie (hauptsächlich für DEBUG-Codeteile, für die Includeguards, und die Includes selber), kille regelmäßig gcc mit Metaprogrammierungsexperimenten :), verwende viele Techniken von Mr.Alexandrescu, von den GoF usw. Soviel zu deinen Meldungen.

[Andi001]

Artchi schrieb:

Werden in den Spielefirmen überhaupt DX-/OGL-Progger gesucht? Benutzen die nicht eh fertige Engines? Als DX-/OGL-Progger findet man bestimmt nur bei Engine-Entwicklern einen Job...

Die meisten Spielefirmen habe ihre eigene Engines. Oder haben gekaufte nach jahrelanger Benutzung schon so abgewandelt, dass sie eh nichtmehr mit der Original-Engine zu vergleichen ist. Z.B. Half-Life 1 Engine, die mal die Quake 1 Engine war und inzwischen zur Source-Engine evolutioniert ist.

(X ist mit jeder beliebigen Version zu ersetzen)
Farcry, eigene Engine (CryEngine)
SeriosSam, eigene Engine (SeriosEngine)
Quake 1-X, eigene Engine
Unreal Tournament, Unreal Engine
Diablo 1+2, eigene Engine
Warcraft 1-3, eigene Engine
Starcraft, eigene Engine
GuildWars, eigene Engine
World of Warcraft, eigene Engine
Arcanum, eigene Engine
Trackmania Original, Sunrise, Nations und United: eigene Engine
Gothic 1+2, eigene Engine, manches Auftragsarbeit.
Gothic 3, Mischung aus verschiedenen Librarys + eigener Code
Command & Conquer X, eigene Engine
Dune X, eigene Engine
Electronic Arts Spiele, eigene Engine
Battle Realms, eigene Engine

Und so weiter und so fort... Wenn ihr wollt kann ich noch mindestens 50 Games aufzählen bei denen die Engine speziell für das Spiel entwickelt wurde oder eine Engine ist, die sich innerhalb der Firma mit jedem Spiel etwas weiterentwickelt. Das sind nur gerade die, die mir so auf Anhieb eingefallen sind.

Faktisch ist es sogar so, dass Sprecher von den Publishern Microsoft, Sierra und anderen ausgesagt haben dass sie skeptisch werden wenn eine Spielefirma nicht ihre eigene Technik entwickelt. Da stellen sich dann die Fragen: Wieso machen die nicht die eigene Technik? Ist das Team überhaupt fähig einen AAA-Titel zu machen?

Andi

Edit:

Firmen werden nicht erfolgreich weil sie die besten Engines schreiben. Unreal, hatte nie den Versuch gestartet Grafisch den ID-Engines nach zu kommen (das versuchen sie erst jetzt mit 2007), sondern die haben sich auf Gameplay konzentriert. Dafür haben sie eine relativ saubere und gute Engine geschrieben. Haben Waffen gemacht mit coolen Sekundär-Funktionen, Jumps und Powerups! Es kommt auf das Team an ob ein Spiel ankommt oder nicht, nicht auf den Publisher.. Denn der wird durch das Team gewählt. Epic hat für jede Unreal Tournament Version einen anderen Publisher der nur für dieses eine Projekt publisht. Das muss heissen, sie haben dafür geschaut dass die Rechte bei ihnen bleiben.

Diablo 2 kam auch nicht wegen atemberaubenden 3D-Effekten an, sondern eher wegen der Story und den coolen Videos die Blizzard damals dafür gemacht hat und weil sie sich sehr viel Mühe mit den Grafiken gemacht haben. Ach und natürlich wegen dem extrem einfachen Spielprinzip, das trotz Einfachheit sehr viele Möglichkeiten bietet. Gameplay! Die Engine war natürlich hochoptimiert und sicher auch möglichst sauber geschrieben. Jedoch war sie eine 2D-Engine und das ganze lief auf 640x480 Auflösung zu einer Zeit wo jeder darauf schwörte dass die zeit der 2D-Games vorbei wäre.

Leider gibt es dieses Blizzard nichtmehr und deswegen wird Diablo 3 eh mist werden. Vorallem da es nicht in ein MMO-Setting passt. Ich erwarte lieber GuildWars 2 von dem alten Blizzard-Team bei ArenaNet, die jetzt wieder genug Geld haben ein 'richtiges' MMO zu machen.

Die meisten Game-Firmen die reich sind, machen Spiele die Spass machen. Deswegen haben sie viel Geld, weil sie das Gameplay und alles richtig gut planen (dazu gehört auch die Engine, die das dann umsetzt). Wer das nicht kapiert, ist selber schuld und wird wohl in der Game-Industrie nie wirklich Erfolg haben.

ID ist nicht nur wegen der Engine die sich angeblich nichtmehr so verkauft, weniger reich sondern wegen dem immergleichen Gameplay! Das ist auch der Grund warum sie jetzt mal mit Enemy Territory was anderes machen wollen!

EA hat soviel verdient, weil sie früh angefangen haben soviele Sportgames zu machen und sich dann die Lizenzen geholt haben. Jetzt sind sie die einzigen mit Lizenz zu den meisten Ligas.

[this-*gt*that]

Andi001 schrieb:

Leider gibt es dieses Blizzard nichtmehr und deswegen wird Diablo 3 eh mist werden. .. blabla... Ich erwarte lieber GuildWars 2 von dem alten Blizzard-Team bei ArenaNet, die jetzt wieder genug Geld haben ein 'richtiges' MMO zu machen.

Omg...

[Andi001]

this->that schrieb:

Andi001 schrieb:

Leider gibt es dieses Blizzard nichtmehr und deswegen wird Diablo 3 eh mist werden. .. blabla... Ich erwarte lieber GuildWars 2 von dem alten Blizzard-Team bei ArenaNet, die jetzt wieder genug Geld haben ein 'richtiges' MMO zu machen.

Omg...

Gibt es ein Problem?

[this-*gt*that]

Nö. Deine Aussagen sind nur äußerst infantil.

[Dravere]

Zum Threadtitel:
Doch, die hier brauchen OpenGL Programmierer -> http://www.battleground-europe.com/scripts/wwiionline/be_info.jsp
Bräuchten wohl 4 - 6 weitere, nur haben sie nicht genügend Geld dafür
Die haben übrigens ihr ganzes Spiel von DirectX auf OpenGL portiert, damit es mit der gleichen Version unter Mac und Windows läuft. Das ist ja auch ein grosser Vorteil von OpenGL, die Platformunabhängigkeit.

Übrigens, hier mal einfach so in den Raum geworfen, zwei OpenGL Engines:
http://www.openscenegraph.org/
-> Jobs: http://www.openscenegraph.org/projects/osg/wiki/Community/JobOffers

http://g3d-cpp.sourceforge.net/

Beide Engines sind übrigens Opensource und können ohne Gebühren frei benutzt werden für kommerzielle oder nicht kommerzielle Produkte. Genaueres steht jeweils bei den Lizenzen.

Vielleicht sollten wir dem Forum mal ein FAQ-Beitrag spenden, wo OpenGL Engines gesammelt werden. ;).

Grüssli

[Andi001]

this->that schrieb:

Nö. Deine Aussagen sind nur äußerst infantil.

Ohne Begründung oder Argumente auf persönlicher Ebene jemanden anzugreifen ist doch viel eher zurückgeblieben, als ich der einfach eine persönliche Meinung zu Blizzard geäussert hat. Diese basiert auf einer Grundlage, du hingegen bläst nur heisse Luft und wirst beleidigend. Auf eine Art die in diesem Forum wahrscheinlich grad noch in der Grauzone liegt... Sehr geschickt

Andi