Niemand braucht OpenGL Programmierer!

hustbaer

GreyHound schrieb:

ich dachte DirectX is praktisch nur n aufgesetztes Framework für Win aber im Kern immer noch OpenGl, habe selbst auch noch kein DirectX verwendet (siehe Wissenschaftliche Anwendungen) also ist es nur ne Vermutung.

Die derzeitige Direct3D Version und OGL unterschieden sich gröbstens. Direct3D ist ein Treiberfeature und hat eine breite Kernelmode Schnittstelle die auch sehr oft verwendet wird (jeder DrawPrimitive Call muss in den Kernelmode schalten!).

Bei OGL ist das nicht so, ist ein reines Usermode Interface, und der Grafikkarten Hersteller kann sich aussuchen wo in den Kernelmode geschaltet wird. Daher ist OGL in einigen Fällen auch schneller, nämlich dann wenn man aus irgendeinem Grund viele kleine Batches rendern muss (bzw. es halt einfach macht).

Natürlich ist das lange nicht der einzige Unterschied, ich wollte damit nur klar machen *wie* unterschiedlich OGL und D3D sind.

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.

rapso

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.

inp

rapso schrieb:

hustbaer schrieb:

Ahja: wenn dann wäre es möglich eine OGL Implementierung zu machen die alles bloss auf D3D abbildet. Umgekehrt ginge das nicht, denn man kann nicht einfach so aus dem Kernelmode raus ein Usermode Teil aufrufen.

beides nur DLLs und klar gibt es von beiden mappings auf die andere schnittstelle, ich hab frueher sowas fuer ogl->d3d3 bzw d3d5 implementiert und auch umgekehrt von d3d8 etc. auf ogl. das ist garkein problem.

/me sich an die alte glide wrapper zeit zurückerinner.

ps: das der thread hier noch lebt ist interessant

rapso

inp schrieb:

ps: das der thread hier noch lebt ist interessant

und das sogar ohne flamewars

thordk

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?

inp

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

rapso

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.

thordk

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.

hustbaer

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.

.filmor

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.

rapso

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

rapso

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.

thordk

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.

hustbaer

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

rapso

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.

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