Verwenden von DXUTSetWindow in einer MFC Direct3D-Anwendung

Question

Ich habe im DirectX SDK vom März 2009 mit den DXUT-Funktionen für Direct3D-Anwendungen experimentiert. Sie scheinen viele nützliche Funktionen zu haben, darunter die automatische Erkennung von DirecX10 oder DirectX9 und Fensterverwaltungsfunktionen, die viele der lästigen Fensterverwaltungsaufgaben umgehen, die normalerweise von Direct3D benötigt werden. Jedoch habe ich ein Problem, wenn ich die DXUTSetWindow Funktion verwende, um Direct3D zu einem bereits erstellten Fenster zeichnen zu lassen. In diesem Fall ist das untergeordnete Ansichtsfenster von CFrameWndEx das Hauptfenster der Anwendung.

Wenn ich den Parameter bHandleMessages auf "true" setze, werden alle Größen und Einstellungen ohne Eingreifen von mir geändert. Aber die Anwendung stürzt ab, wenn ich versuche, das Programm zu schließen (und sofort verlasse, so dass ich nicht einmal brechen kann, um zu sehen, was den Absturz verursacht) mit einer Menge Speicherlecks. Wenn ich bHandleMessages auf false setze, funktioniert keine der Größenanpassung, aber ich bekomme keinen Absturz oder Speicherlecks beim Beenden.

Es sieht so aus, als ob die DXUTMainLoop nach einer WM_QUIT Nachricht sucht, um alle Direct3D-Objekte zu beenden und dann aufzuräumen, die nie von dem unterordneten Fenster empfangen werden. Ich habe versucht, nach dem ohne Erfolg:

1. Aufschalten der CFrameWndEx ‚s OnClose Funktion und manuell eine WM_QUIT Nachricht an das Kind zu senden.
2. Setzen Sie den DXUTMainLoop Aufruf auf einen Worker-Thread.
3. Überschreiben CFrameWndEx::DefWindowProc und Verwenden der DXUTStaticWndProc Funktion (die die DXUT-Dokumentation sagt zu verwenden, wenn DXUTSetWindow verwendet wird, aber in keinem der Beispiele zu zeigen, zu vernachlässigen).
4. Einstellung des Fensters zur Verwendung des Handles CFrameWndEx und Erstellen einer separaten Swap-Kette für das untergeordnete Fenster. Es scheint, dass DXUT das Handle, das in DXUTSetWindow verwendet wird, schwarz auslöscht, unabhängig davon, ob etwas in dem OnD3D9FrameRender-Rückruf ausgeführt wird.

UPDATE: Nach dem Überschreiben der DefWindowPro c des Kindes Fenster und ruft DXUTStaticWndProc von dem Kind Fenster DefWindowProc, ich war in der Lage, die Anwendung zu erhalten auszuführen, die Größe, Griff Gerät verloren und verlassen, ohne den Absturz, Speicherlecks . Dies geschieht, indem bHandleMessages auf false gesetzt wird. Dies verursacht jedoch ein neues Problem:

Die Direct3D-Zeichnungsoberfläche ist ein paar Pixel kleiner als der Bereich des untergeordneten Fensters und hinterlässt einen Rand von Videorauschen, der die Zeichenoberfläche umgibt. Dies passiert nicht, wenn bHandleMessages wahr ist, obwohl es auf derselben HWND in der gleichen DXUTStaticWndProc Funktion arbeitet.

UPDATE 2: Es sieht so aus, als ob das Pixelproblem jetzt gelöst ist. Mit der Regelung von der ersten Aktualisierung auf diese Frage fand ich mich brauchte nur CWnd::DefWindowProc rufe in dem DefWindowProc nur außer Kraft gesetzt Kinder Fenster, wenn DXUTStaticWndProc nicht zurückkehren 0. Der folgende Code So scheint es zu lösen:

LRESULT ChildView::DefWindowProc(UINT message, WPARAM wParam, LPARAM lParam){ 

    LRESULT lr = DXUTStaticWndProc(this->GetSafeHwnd(), message, wParam, lParam); 
    if(lr != 0) { 
     return CWnd::DefWindowProcW(message, wParam, lParam); 
    } 

    return lr; 
} 

Meine andere Frage steht noch, lohnt es sich überhaupt, die DXUT-Bibliothek zu verwenden? Wie sehr wird es mich einschränken, was ich mit DirectX machen kann? Sollte ich einfach alle Direct3D-Objekte, Geräteeinstellungen/-resets und Rendering manuell verwalten?

Answer 1

Meiner Meinung nach ist die DXUT-Bibliothek Junk.Ich würde einfach den von Ihnen benötigten Code stehlen und ihn direkt in Ihre Anwendung einfügen und Refactorings großzügig anwenden. Die ganze DXUT-Philosophie scheint zu sein: "Obwohl die Leute 2009 denken, dass Objekte schwer sind, werden wir die Wayback-Maschine für 1988 setzen und alles C-Stil mit globalen Funktionen programmieren." Es ist einfach schrecklich.