4. OpenGl und DirectX in einer Engine

OpenGl und DirectX in einer Engine

  • I

    Hi,

    ich will mit einem Freund, der im Gegensatz zu mir recht fit in OpenGl ist, eine neue 3D-Engine (eigentlich mehr ein Wrapper) programmieren.

    Wir wollen so vorgehen:

    Es gibt einen Satz von Basisklassen mit virtuellen Funktionen von denen sich jeweils die OpenGL und DirectX Implementierungen ableiten sollen.

    so in der Art (vereinfacht):

    class EngineBasis
{
    virtual void Clear( long color ) = NULL;
};

class D3DBasis : EngineBasis
{
    void Clear( long color)
    {
        //Direct3D Implementierung
        this->D3DDevice->Clear( 0,NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, color ,1.0f,0);
    }
};

class OpenGLBasis : EngineBasis
{
    void Clear( long color )
    {
        // OpenGL Implementierung
        glClearColor( (color >> 16 & 0xff) / 255.f  , (color >> 8 & 0xff)/255.f, (color & 0xff)/255.f, (color >> 24 & 0xff)/255.f );
        glClearDepth(1);
        glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
    }
};

    Meine Fragen:

    1. Macht diese Methode überhaupt so Sinn, wenn man OpenGl und DirectX in einer Engine haben will? Welche alternative sind eventuell besser?

    2. Gibt es zu jeder Direct3D Methode überhaupt entsprechungen in OpenGl die immer genau das selbe tun, oder komme ich irgendwann an einen Punkt, wo ich merke, dass sich D3D und OpenGl nicht unter einem einheitlichem Wrapper vereinen lassen? Soweit ichmich erinnere gibts ja in OpenGL nichts vergleichbares zu z.B. dem D3D Flexible-Vertex-Format oder Vertex-/Index-Buffern bzw. es ist vom Handling komplett anders.

    0
  • P

    Hi,

    zu 1.: Türlich würde das Sinn machen, so wäre ne Portierung auf andere Systeme leichter und für User die nunmal ne etwas bessere OpenGL Karte haben als DX Karte (oder umgekehrt) würde das sehr viel Sinn machen.

    zu 2.: Du wirst oft an diesen Punkt kommen, drum empfiehlt es sich so eine Art "ZwischenAPI" zu coden, also das Deine Engine eine eigene API ist, die nur halt DX bzw. OpenGL benutzt eben um dieses Hindernis mit dem Handlingsache zu überwinden. Darin würd sich auch eine Mathelib gutmachen eben um von D3DX loszukommen.

    0
  • I

    Patrick schrieb:

    Darin würd sich auch eine Mathelib gutmachen eben um von D3DX loszukommen.

    Für den D3DX-Mathe Kram hab ich mir schon jede Menge Ersatz geschrieben (als Intro-Programmierer kommt man da nicht drum rum).

    Aber noch ne Frage dazu. Kann ich trotzdem auch in der OpenGL-Implementierung Typen und Structs aus D3D/D3DX verwenden? Gibt das Probleme wenn die OpenGL-Variante auf einem Rechner ohne DirectX ausgeführt wird? Und wenn ich z.B. D3DXVec3Add inline verwende müsste das doch auch gehen, oder?

    Ich würde nämlich gern Sachen wie diese verwenden:

    struct Vector3
{
    union
    {
        struct{float x,y,z;};
        D3DVECTOR p;
    };
};
    0

  • Patrick schrieb:

    Darin würd sich auch eine Mathelib gutmachen eben um von D3DX loszukommen.

    Man kann ja für den DX Teil trotzdem die hochoptimierten Sachen von MS nehmen.

    Bye, TGGC \-/

    0
  • P

    TGGC schrieb:

    Patrick schrieb:

    Darin würd sich auch eine Mathelib gutmachen eben um von D3DX loszukommen.

    Man kann ja für den DX Teil trotzdem die hochoptimierten Sachen von MS nehmen.

    Bye, TGGC \-/

    Hm das stimmt allerdings! Was auch noch ne Möglichkeit wäre, wären Grundfunktionen von der D3D Mathe und der OpenGL Mathe sich nicht unterscheiden in eigene Funktion zu stecken wie z.B. Matrizenmultiplikationen oder anderen Kram. Drüfte speed geben.

    0
  • G

    illuminator schrieb:

    Ich würde nämlich gern Sachen wie diese verwenden:

    struct Vector3
{
    union
    {
        struct{float x,y,z;};
        D3DVECTOR p;
    };
};

    Würde ich nicht, da unnamed struct's in C++ nicht erlaubt sind. Für sowas gibts meist bessere Lösungen.
    Ausserdem würde ich nicht so einen Mix machen. Entweder du benutzt dür den Mathe Teil der Engine zB für die D3D Implementierung komplett D3D(X) Funktionen oder komplett eigene Funktionen.

    0

  • War da nicht irgendwas mit den Matrizen, die wurden glaube ich anders gespeichert. Das würde eine portable MatheLib doch erschweren...

    Bye, TGGC \-/

    0
  • I

    groovemaster2002 schrieb:

    illuminator schrieb:

    Ich würde nämlich gern Sachen wie diese verwenden:

    struct Vector3
{
    union
    {
        struct{float x,y,z;};
        D3DVECTOR p;
    };
};

    Würde ich nicht, da unnamed struct's in C++ nicht erlaubt sind. Für sowas gibts meist bessere Lösungen.
    Ausserdem würde ich nicht so einen Mix machen. Entweder du benutzt dür den Mathe Teil der Engine zB für die D3D Implementierung komplett D3D(X) Funktionen oder komplett eigene Funktionen.

    Ok, wenn es "nicht erlaubt" ist, warum ist es dann möglich? Bzw. was ist so schlimm daran, dieses außerordentlich praktische Feature zu verwenden?

    0
  • P

    TGGC schrieb:

    War da nicht irgendwas mit den Matrizen, die wurden glaube ich anders gespeichert. Das würde eine portable MatheLib doch erschweren...

    Bye, TGGC \-/

    Jo das kenn ich noch von meinem Umstieg auf OpenGL, Direct3D ließt die Matrizen Zeilenweise ein aber OpenGL Spaltenweise.

    Bei D3D:
_11,_12,_13,_14
_21,_22,_23,_24
_31,_32,_33,_34
_41,_42,_43,_44

Bei OpenGL
_11,_21,_31,_41
_12,_22,_32,_42
_13,_23,_33,_43
_14,_24,_34,_44

    EDIT: http://www.zfx.info/DisplayThread.php?TID=15175 🙄

    0
  • G

    illuminator schrieb:

    Ok, wenn es "nicht erlaubt" ist, warum ist es dann möglich?

    Das liegt daran, dass der Compiler deiner Wahl das unterstützt (Thema Compilererweiterungen). Fakt ist aber, dass ISO C++ es nicht erlaubt. Sollte jemand deinen Code mit einem anderen (Standard-)Compiler übersetzen, so bekommt er lästige Warnungen oder wird im worst-case es überhaupt nicht übersetzen können.

    illuminator schrieb:

    Bzw. was ist so schlimm daran, dieses außerordentlich praktische Feature zu verwenden?

    Ich versteh nicht was an deiner Vector3 Implementierung damit so außerordentlich praktisch sein soll? Ein ähnliches Thema und wie man es imo besser lösen kann hatten wir letztens erst.

    0
  • I

    thx, wieder was gelernt.

    0

  • Ist aber nicht so flexibel wie union. Perfomanz müsste man erstmal testen.

    Bye, TGGC \-/

    0
  • S

    Denk' auch dran daß bei OpenGL das Koordinatensystem anders herum ist, zudem die "permanente Kamera" genau antiparallel zu DX's ist, OpenGL std.mäßig nur 8 Lights unterstützt, etc. pp
    Zerbie zeigt in seinem neuen Buch eine API-unabhängige Engine zu bauen.
    David Eberly hat in seinem (mittlerweile älteren) Buch über "3D Engine Design" auch eine API-unabhängige Implementation versucht, über ein Interface, der Teil für OpenGL ist auch implementiert. Source dazu solltest Du auf seiner Firmenseite bekommen... http://www.magic-software.com/

    0
  • G

    TGGC schrieb:

    Ist aber nicht so flexibel wie union

    Es ging nicht um union, sondern um unnamed structs. unions kannst du von mir aus verwenden bis zum Abwinken (auch unnamed). Interessant wäre ausserdem, wenn du mal erkären könntest was nicht so flexibel sein soll.

    0

  • groovemaster2002 schrieb:

    Hab gedacht, dass das Problem am besten mit union zu lösen wäre. Davon hab ich mich mittlerweile distanziert.

    Der [] Operator hat einen festen Rückgabe-Typ. Die Strukturen können sich aus verschiedenen Typen zusammensetzen.

    Bye, TGGC \-/

    0
  • G

    TGGC schrieb:

    Die Strukturen können sich aus verschiedenen Typen zusammensetzen.

    Tun sie aber nicht in diesem Fall, und ich hab ja auch nie behauptet, dass unions immer die schlechtere Lösung sind. Dass es ausserdem für jedes Problem die universelle Lösung gibt, sollte dir ja auch klar sein.

    0
Anmelden zum Antworten