Hi,

weiß jemand von euch wie die ganzen Spiele entwickler das angehen wenn sie ein Spiel für sowohl OpenGL als auch D3D entwickeln?
Ich meine, klar.. man kann den code insofern abstrahieren das man alles in klassen abkapselt was die API selbst betrifft und dann einfach die klassen austauscht..

aber:

1) Wie schaut es aus mit wirklich API spezifischen dingen.. auch wenn mir da grad so spontan nichts einfällt (dafür kenne ich D3D zuwenig), aber es gibt doch sicher dinge die sich nicht so einfach gleich machen lassen beiden beiden APIs oder? Also so, dass man nicht beides unbedingt einfach in die gleiche klasse abstrahieren kann...

2) Wie schaut es aus mit Shadern? Gibt es da nen weg eine kompatibilität zwischen GLSL und HLSL zu schaffen? Oder muß man die halt 2x schreiben..?

Aya~

for gl3ds i made an attempt for render targets. http://www.noeska.net/downloads/gl3ds_r ... alpha1.zip
i made a generic baseclass in render and an inherited implementation for opengl in glrender and have done the same for the other classes.

the problem with supporting both opengl and d3d is the coord systems are different, on top of that you need to support shaders for both d3d and opengl.

ati is suposed to have a conversion tool for converting hlsl to glsl. (http://sourceforge.net/projects/hlsl2glsl)

why not also use opengl under windows?

_________________
http://3das.noeska.com - create adventure games without programming

Schreibt man auf unterschiedlichen Bibliotheken, dann gibt es natürlich Funktionen und Features, die nicht beide gleichermaßen können und darum hat man ja abstrakte Klassen. Diese legen den gemeinsamme größte Menge fest und alles ausserhalb wird entweder fixed im Gamecode hinzugepackt(ifdef,else,endif) oder garnicht benutzt.
Der erste Fall tritt extrem selten auf, wenn überhaupt und das liegt daran, dass du momentan von der falschen Seite herran gehst.
Du hast am Ende ein Spieler, dieser ist eine Klasse(TPlayer) und diese enthält Variablen zu Klasse(TKI,TModel), welche wieder Klassen besitzen(TMesh, TMaterial, TPathfinding, TBehavior, TStateMachine, ...).
Deine TMesh Klasse kann dann z.B. von einem Grafik Kontext erstellt werden(TMeshOpenGL, TMeshD3D, TMeshOpenVL, TMeshOpenCL,...) und über TMesh wird es modifiziert. Dein Mesh wird von TModel entsprechend verwendet und diese Methoden werden in der jeweiligen Bibliothek realisiert und dabei versucht man es so um zu setzen, dass es möglichst schnell und soviel Hardware wie möglich supported. Du kannst also in deiner TMeshOpenGL Version Immediate verwenden und in TMeshOpenGL30 VBO, um dein Mesh zu realisieren. Innerhalb der Klasse kannst auch defines benutzen und z.B. bei bestimmten CPUs, Binary Architektur andere Implementierungen verwenden aber das passiert innerhalb der Klasse und ist nach aussen nicht bemerkbar.
Generiere und verwalte deine Ressourcen über Manager.
Der Manager für Grafik sachen wäre dann z.B. ein TGraphicContext welcher TGraphicContextClassOpenGL oder TGraphicContextClassD3D ableitet.
Damit werden alle Ressourcen automatisch für die korrekten Bibliothek verwendet und man kann ganz einfach an einer Stelle die verwendete Bibliothek fest legen.


Zum Thema Shader gibt es 2 Wege.
Der erste Weg ist der klassische alte Weg über mehrere Shader für die jeweilige Grafikkarte und Bibliothek und die moderne Variante sind Bibliotheken wie CG, welche eine neue Scriptsprache in die entsprechenden Shader für eine Bibliothek konvertieren und dann in der Bibliothek compilieren.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Meine 2D-Engine kann auch sowohl OpenGL als auch Direct3D verwenden. Den kompletten Sourcecode gibt es hier:

http://andorra.cvs.sourceforge.net/view ... dorra/src/

Im Prinzip habe ich eine Abstraktionsebene für die Grafikschnittstelle geschrieben und lade die entsprechende Implementierung über ein Plugin herein. Bei der Entwicklung der Abstraktionsebene bin ich zunächst von Direct3D ausgegangen und habe erst nachdem die Schnittstelle fertig war OpenGL implementiert. Ich bin auf keine Probleme gestoßen. Du musst die API so weit herunterbrechen, dass du auf keine spezifischen Features stößt.
Zum Beispiel kann Direct3D direkt Texturen aus JPEG, PNG, DDS etc. Dateien laden. Diese Funktion sollte nicht in deine Schnittstelle, da sie zu spezifisch ist. Trotzdem gäbe es kein Problem, selbst wenn diese Funktion vorhanden wäre: Dann musst du die Ladefunktionen für OpenGL halt extra schreiben.

Bei Shadern setze ich auf folgenden weg:
Die Grafikplugins stellen ein abstraktes Shaderinterface bereit, das zurückgibt, ob eine bestimmte Sprache unterstützt ist. HLSL Shader werden von Direct3D, Cg von Direct3D und OpenGL, GLSL Shader nur von OpenGL unterstützt.

Interessante Dateien in meiner Engine:
Schnittstellendefinition: http://andorra.cvs.sourceforge.net/view ... iew=markup
Shaderschnittstellendefiniton: http://andorra.cvs.sourceforge.net/view ... iew=markup

OpenGL-Implementierung: http://andorra.cvs.sourceforge.net/view ... iew=markup
Direct3D-Implementierung: http://andorra.cvs.sourceforge.net/view ... iew=markup

_________________
http://audorra.sourceforge.net//http://andorra.sourceforge.net