Niemand braucht OpenGL Programmierer!
-
Krux schrieb:
rapso schrieb:
wieso sollte eine fertige engine sowas nicht ermoeglichen?
schonmal darwinia gezoggt? Da gibts effekte, die gibts nur in Darvinia, sonst nirgends, und ich weis auch nicht, ob man diese neon leuchtwelt so einfach mit einer fertigen engine hinbekommen hätte, jedenfalls bestimmt nicht so gut.
Soll das ein Witz sein? Die Grafik (laut Screenshots) hab ich schon damals auf meinem Acorn Archimedes gehabt, wenn auch in kleinerer Auflösung und weniger Farben. Aber vom Prinzip her ist das ein alter Hut. Retro auf aktueller Hardware. Und gerade weil es so simple ist, hat man wohl eine eigene "Engine" programmiert.
-
sieht aber lustig aus
aktuelle engines kümmern sich nicht nur um die grafik. das können die natürlich auch und je nach engine wird mit primitiven gearbeitet oder gleich ganzen models. das wichtigste an modernen engines ist aber, was die sonst noch so für fluff bieten. skeletons, physik, partikeleffekte, stoffsimulation usw. deshalb wird man auch nicht unbedingt nen dx/ogl entwickler einstellen, wenn sich jemand um die engine kümmern soll. low level grafik ist halt nur nen teilgebiet.
-
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.
-
Deine Vermutung ist völliger Unfug.
-
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.
-
hustbaer schrieb:
Ahja: wenn dann wäre es möglich eine OGL Implementierung zu machen die alles bloss auf D3D abbildet. Umgekehrt ginge das nicht, denn man kann nicht einfach so aus dem Kernelmode raus ein Usermode Teil aufrufen.
beides nur DLLs und klar gibt es von beiden mappings auf die andere schnittstelle, ich hab frueher sowas fuer ogl->d3d3 bzw d3d5 implementiert und auch umgekehrt von d3d8 etc. auf ogl. das ist garkein problem.
-
rapso schrieb:
hustbaer schrieb:
Ahja: wenn dann wäre es möglich eine OGL Implementierung zu machen die alles bloss auf D3D abbildet. Umgekehrt ginge das nicht, denn man kann nicht einfach so aus dem Kernelmode raus ein Usermode Teil aufrufen.
beides nur DLLs und klar gibt es von beiden mappings auf die andere schnittstelle, ich hab frueher sowas fuer ogl->d3d3 bzw d3d5 implementiert und auch umgekehrt von d3d8 etc. auf ogl. das ist garkein problem.
/me sich an die alte glide wrapper zeit zurückerinner.
ps: das der thread hier noch lebt ist interessant
-
inp schrieb:
ps: das der thread hier noch lebt ist interessant
und das sogar ohne flamewars
-
rapso schrieb:
hustbaer schrieb:
Ahja: wenn dann wäre es möglich eine OGL Implementierung zu machen die alles bloss auf D3D abbildet. Umgekehrt ginge das nicht, denn man kann nicht einfach so aus dem Kernelmode raus ein Usermode Teil aufrufen.
beides nur DLLs und klar gibt es von beiden mappings auf die andere schnittstelle, ich hab frueher sowas fuer ogl->d3d3 bzw d3d5 implementiert und auch umgekehrt von d3d8 etc. auf ogl. das ist garkein problem.
wenns kein problem darstellt, warum gibs dann noch keinen anständigen dx9.0c wrapper für wine?
-
thordk schrieb:
rapso schrieb:
hustbaer schrieb:
Ahja: wenn dann wäre es möglich eine OGL Implementierung zu machen die alles bloss auf D3D abbildet. Umgekehrt ginge das nicht, denn man kann nicht einfach so aus dem Kernelmode raus ein Usermode Teil aufrufen.
beides nur DLLs und klar gibt es von beiden mappings auf die andere schnittstelle, ich hab frueher sowas fuer ogl->d3d3 bzw d3d5 implementiert und auch umgekehrt von d3d8 etc. auf ogl. das ist garkein problem.
wenns kein problem darstellt, warum gibs dann noch keinen anständigen dx9.0c wrapper für wine?
die schiere funktionsvielfalt + optimierungen für verschiedene hardware würd ich mal sagen
-
thordk schrieb:
rapso schrieb:
hustbaer schrieb:
Ahja: wenn dann wäre es möglich eine OGL Implementierung zu machen die alles bloss auf D3D abbildet. Umgekehrt ginge das nicht, denn man kann nicht einfach so aus dem Kernelmode raus ein Usermode Teil aufrufen.
beides nur DLLs und klar gibt es von beiden mappings auf die andere schnittstelle, ich hab frueher sowas fuer ogl->d3d3 bzw d3d5 implementiert und auch umgekehrt von d3d8 etc. auf ogl. das ist garkein problem.
wenns kein problem darstellt, warum gibs dann noch keinen anständigen dx9.0c wrapper für wine?
es gibt einen wrapper fuer wine, kannst ja sims spielen. die qualitaet hat dabei nichts mit technischer machbarkeit zu tun.
-
wollte ich nur sims spielen, gäbe ich das spielen ganz auf ^^ aber da ich das nicht will und kaum nen entwickler auf ogl setzt, werd ich mich wohl weiterhin mit windows rumprügeln müssen.
-
rapso schrieb:
hustbaer schrieb:
Ahja: wenn dann wäre es möglich eine OGL Implementierung zu machen die alles bloss auf D3D abbildet. Umgekehrt ginge das nicht, denn man kann nicht einfach so aus dem Kernelmode raus ein Usermode Teil aufrufen.
beides nur DLLs und klar gibt es von beiden mappings auf die andere schnittstelle, ich hab frueher sowas fuer ogl->d3d3 bzw d3d5 implementiert und auch umgekehrt von d3d8 etc. auf ogl. das ist garkein problem.
D3D ist eine DLL (bzw. mehrere), ja, aber eine von Microsoft vorgegebene.
Ein Treiber der D3D "kann" stellt bloss eine Kernelmode Schnittstelle zur Verfügung. D.h. man kann nicht einfach einen Treiber schreiben der dann alles auf OGL umlenkt.
Wenn man natürlich nicht davor zurückschreckt die D3D DLLs auszutauschen... ist das wieder eine andere Sache.
-
thordk schrieb:
wollte ich nur sims spielen, gäbe ich das spielen ganz auf ^^ aber da ich das nicht will und kaum nen entwickler auf ogl setzt, werd ich mich wohl weiterhin mit windows rumprügeln müssen.
So mies siehts mir der Wine-Unterstützung doch gar nicht aus. FlatOut 2 zum Beispiel läuft ohne Probleme und ist mE ein Direct3D 9 Spiel.
Was ich aber irgendwie lustig finde ist, dass zb EA jetzt mehr Spiele auf OS X portieren will. Also schreiben sie es erst mit Direct3D um es dann doch auf OpenGL umzumodeln.
-
thordk schrieb:
wollte ich nur sims spielen, gäbe ich das spielen ganz auf ^^ aber da ich das nicht will und kaum nen entwickler auf ogl setzt, werd ich mich wohl weiterhin mit windows rumprügeln müssen.
emm..jaaa... schoen fuer dich
-
hustbaer schrieb:
Wenn man natürlich nicht davor zurückschreckt die D3D DLLs auszutauschen... ist das wieder eine andere Sache.
ja, genau so macht man die wrapper.
-
sollen sie halt gleich in java und ogl entwickeln ^^ www.jmonkeyengine.com die engine find ich klasse, ist nen demo video von der javaone in den news.
-
rapso schrieb:
hustbaer schrieb:
Wenn man natürlich nicht davor zurückschreckt die D3D DLLs auszutauschen... ist das wieder eine andere Sache.
ja, genau so macht man die wrapper.
Geht das eigentlich auch wenn nicht die originalen D3D DLLs überschreibt sondern einfach nur gleichnamige DLLs ins gleiche Verzeichnis mit der .exe legt?
Das wäre unter Windows dann ja ein akzeptabler Weg - weil die D3D DLLs global austauschen finde ich etwas heftig.(Für WINE und Konsorten ist das natürlich egal, die müssen ja sowieso ihre eigenen D3D DLLs haben...)
-
hustbaer schrieb:
rapso schrieb:
hustbaer schrieb:
Wenn man natürlich nicht davor zurückschreckt die D3D DLLs auszutauschen... ist das wieder eine andere Sache.
ja, genau so macht man die wrapper.
Geht das eigentlich auch wenn nicht die originalen D3D DLLs überschreibt sondern einfach nur gleichnamige DLLs ins gleiche Verzeichnis mit der .exe legt?
Das wäre unter Windows dann ja ein akzeptabler Weg - weil die D3D DLLs global austauschen finde ich etwas heftig.ich hab die bisher nur lokal ausgetauscht, bzw im game ne andere dll laden lassen. die globale DLL auszutauschen waere echt evil.
-
rapso schrieb:
hustbaer schrieb:
rapso schrieb:
hustbaer schrieb:
Wenn man natürlich nicht davor zurückschreckt die D3D DLLs auszutauschen... ist das wieder eine andere Sache.
ja, genau so macht man die wrapper.
Geht das eigentlich auch wenn nicht die originalen D3D DLLs überschreibt sondern einfach nur gleichnamige DLLs ins gleiche Verzeichnis mit der .exe legt?
Das wäre unter Windows dann ja ein akzeptabler Weg - weil die D3D DLLs global austauschen finde ich etwas heftig.ich hab die bisher nur lokal ausgetauscht, bzw im game ne andere dll laden lassen. die globale DLL auszutauschen waere echt evil.
ein hardlink auf die dll wär ne gute idee, kann man per script auch umschaltbar machen so.
