D3D device release bei DestroyWindow notwendig?



  • Weiß ich doch nicht. Ich benutze .Net und kenne nicht die äquivalenten Windows API aufrufe. Ich kann mein Form resizen und verschieben. Du musst dafür kein neues Fenster erstellen.



  • Jo hab ich auch eben rausgefunden 🙄
    Die Frage war ja ned direkt an dich gerichtet.

    MfG

    EDIT:
    Ich frag das lieber im WINAPI Forum



  • TGGC schrieb:

    Andi001 schrieb:

    Ich denke nicht dass es sinvoll ist, kurzzeitig zwei Fenster zu haben wenn man doch nur eines braucht.

    Wenn man nur eines braucht, warum will man es dann ueberhaupt wechseln? f'`8k

    Autocogito

    Gruß, TGGC (making great games since 1992)

    Aus dem Grund wie ich weiter oben in meinem Post geschrieben habe. Z.B. OpenGL<->Direct3D Renderer-Wechsel, nicht zu vergessen Window-Style änderungen (Fullscreen ohne Border, Fenstermodus mit Border etc.). Sollte Dir eigentlich klar sein, weil Du ja schon so lange hier bist...

    Wegen dem anderen Problem: Das Programm schliesst sich, weil Du wahrscheinlich die WM_DESTORY-Message abfängst. Immer wenn Du mit DestroyWindow() ein Fenster zerstörst, bekommt dessen Window-Prozedur natürlich die WM_DESTROY-Nachricht. Reagiert deine WindowProzedur mit dem Beendes des Programms darauf, ist dann natürlich nicht nur das Fenster geschlossen 🙂

    Edit:

    Hier ein kleines Schnippsel aus meinem Prog was bei der Lösung helfen könnte:

    case WM_DESTROY:
             // Wenn die Auflösung gewechselt wird, wird das Fenster zerstört.
             // Dies wird jedoch von Platform::createWindow()/Platform::destroyWindow()
             // schon richtig gehandhabt. Also mache ich einfach nichts, da das Fenster
             // schon richtig zerstört wurde. So wird keine PostQuitMessage(0) geschickt,
             // die das ganze Programm beenden würde.
             break;
          case WM_CLOSE:
             // Löst ein QuitEvent aus.
             PostQuitMessage(0);
             return 0;
    

    Edit 2: (uhm bin heute nur am Editieren^^)

    Also das mit der PostQuitMessage(0) ist halt so, dass man normalerweise in der Schleife guckt ob die Message == WM_QUIT ist und reagiert darauf mit dem beenden des Programms. Sendet man also bei WM_DESTROY ein Quit-Signal, wird das ganze Programm beendet. Bei mir wird dabei halt dann ein QuitEvent an die Applikation gesendet.



  • Jo danke Andi, aber man muss kein neues Fenster erstellen:

    void Window::changeWindow(bool fullscreen, int width, int height)
    {
    	if(fullscreen)
    	{
    		SetWindowLong(windowHandle, GWL_STYLE, WS_POPUP | WS_VISIBLE);
    		SetWindowPos(windowHandle, HWND_TOPMOST, 0, 0, 0, 0, SWP_FRAMECHANGED);
    	}
    	else
    	{
    		SetWindowLong(windowHandle, GWL_STYLE, WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX | WS_VISIBLE);
    		SetWindowPos(windowHandle, HWND_TOPMOST, 0, 0, width, height, SWP_FRAMECHANGED);
    	}
    }
    

    MfG



  • Wird dabei wirklich der Fenster-Style geändert? Bei mir hat das meistens nicht geklappt.

    Naja ich muss sowieso das Fenster neu erstellen bei mir, wenn Renderer-Wechsel angesagt ist. Von daher ist das egal 🙂

    Bei der Höhe und Breite deines Fensters, fehlt aber doch der Border oder? Wenn Dein Programm 1024x768 rendert z.B. fehlen da ein paar Pixel dann im Client-Bereich wenn Du deine Funktion mit diesen Werten aufrufst. Betrifft nur den Fenstermodus.

    Andi001



  • Andi001 schrieb:

    Aus dem Grund wie ich weiter oben in meinem Post geschrieben habe. Z.B. OpenGL<->Direct3D Renderer-Wechsel, nicht zu vergessen Window-Style änderungen (Fullscreen ohne Border, Fenstermodus mit Border etc.). Sollte Dir eigentlich klar sein, weil Du ja schon so lange hier bist...

    Ja, ich bin schon laenger da. Aber bisher hat mir noch niemand erzaehlt, das wenn ich Fenstergroessen und Stile nur an neuen Fenstern greaendert werden duerfen. Ist das ein neues Feature von Vista? 😉

    Gruß, TGGC (making great games since 1992)



  • TGGC schrieb:

    Andi001 schrieb:

    Aus dem Grund wie ich weiter oben in meinem Post geschrieben habe. Z.B. OpenGL<->Direct3D Renderer-Wechsel, nicht zu vergessen Window-Style änderungen (Fullscreen ohne Border, Fenstermodus mit Border etc.). Sollte Dir eigentlich klar sein, weil Du ja schon so lange hier bist...

    Ja, ich bin schon laenger da. Aber bisher hat mir noch niemand erzaehlt, das wenn ich Fenstergroessen und Stile nur an neuen Fenstern greaendert werden duerfen. Ist das ein neues Feature von Vista? 😉

    Gruß, TGGC (making great games since 1992)

    Ich weiss es nicht. Bei Renderer-Wechsel muss ich auf jedenfall das Fenster neu erstellen. Also wenn ich von OpenGL auf Direct3D wechsel oder so etwas. Dadurch wird das komplette neu erstellen des Fensters natürlich zur saubersten Lösung die immer funktioniert.



  • Andi001 schrieb:

    Wird dabei wirklich der Fenster-Style geändert? Bei mir hat das meistens nicht geklappt.

    Jo, funktioniert. Wichtig ist nur, WS_CAPTION zu setzen, sobald man wieder in den Fenstermodus will. Sonst klappts nicht mit dem border.

    Andi001 schrieb:

    Naja ich muss sowieso das Fenster neu erstellen bei mir, wenn Renderer-Wechsel angesagt ist. Von daher ist das egal 🙂

    Keine Ahnung. Das window-Handle hast du ja, reicht das nicht?

    Andi001 schrieb:

    Bei der Höhe und Breite deines Fensters, fehlt aber doch der Border oder? Wenn Dein Programm 1024x768 rendert z.B. fehlen da ein paar Pixel dann im Client-Bereich wenn Du deine Funktion mit diesen Werten aufrufst. Betrifft nur den Fenstermodus.

    Weiß jetzt nicht was du meinst. Im Fullscreen braucht man keine Fenstergröße anzugeben.

    MfG



  • Ja, also ich verstehs auch nicht, was Andi fuer Probleme hat. Ist ja nicht so, das DX das Fenster irgendwie kaputt machen wuerde. f'`8k

    Autocogito

    Gruß, TGGC (making great games since 1992)



  • @ceplusplus

    Ich meine damit, dass wenn du mit SetWindowPos() ein Fenster machst. Hat das Fenster nachher die Abmessungen von z.B. 1024x768 (mit Titel-Leiste und Ränder), nicht aber der Client-Bereich. Da musst Du also entweder Direct3D mit einer Auflösung initialisieren die der Grösse des Client-Bereichs angepasst ist oder das Fenster etwas grösser machen (Breite/Hoehe der verschiedenen Bereiche lässt sich mit GetSystemMetrics() herausfinden).

    Initialisierst du Direct3D (ob mit Reset oder neu) dabei auch mit den 1024x768 (aus dem Beispiel oben), wird ein teil von deiner Szene unten und rechts nicht zu sehen sein.

    @TGGC

    Habe wohl das WS_CAPTION vergessen (thx@ceplusplus: werd das mal ausprobieren), weil ohne das hat Direct3D mein Fenster tatsächlich kaputt gemacht oder nicht an der Position des Client-Bereichs gerendert, wenn ich mit Reset() gearbeitet habe. Gab z.T. ziemlich komische Resultate (Edit: Mag vielleicht auch daran liegen, dass ich mit MoveWindow() gearbeitet habe). ATM habe ich aber leider keine Zeit mich um diesen Teil des Codes zu kümmern, funktioniert ja jetzt alles wie es soll. Werde mich später mal darum kümmern^^

    Andi



  • Andi001 schrieb:

    Ich meine damit, dass wenn du mit SetWindowPos() ein Fenster machst. Hat das Fenster nachher die Abmessungen von z.B. 1024x768 (mit Titel-Leiste und Ränder), nicht aber der Client-Bereich. Da musst Du also entweder Direct3D mit einer Auflösung initialisieren die der Grösse des Client-Bereichs angepasst ist oder das Fenster etwas grösser machen (Breite/Hoehe der verschiedenen Bereiche lässt sich mit GetSystemMetrics() herausfinden).

    Hmm, hab das jetzt so probiert:

    SetWindowPos(windowHandle, HWND_TOPMOST, 0, 0, width + GetSystemMetrics(SM_CYDLGFRAME), height + GetSystemMetrics(SM_CXDLGFRAME), SWP_FRAMECHANGED);
    

    Scheint aber keinen Effekt zu haben 😕

    MfG



  • Achso nene hat eh funktioniert. Hatte es nur gar nicht aufgerufen 🙄
    Aber: Kann mir jemand bestätigen, dass die CAPTION auch einen Border hat? Denn:

    Für die Gesamtbreite:
    width + GetSystemMetrics(SM_CYDLGFRAME) * 2

    Für die Gesamthöhe:
    height + GetSystemMetrics(SM_CYCAPTION) + GetSystemMetrics(SM_CXDLGFRAME) * 2

    Also scheint unter der CAPTION auch ein horizontaler Rand zu sein? Habs mit "Pixelmeter" (Cooles Tool) nachgemessen, stimmt anscheinend so.

    MfG



  • Muesste es dann nicht * 3 heissen: oben, untem und unter der Caption. f'`8k

    Autocogito

    Gruß, TGGC (making great games since 1992)



  • Wollt mich vergewissern, wie das Fenster aufgebaut ist. Aber ich glaube der obere Bereich besteht nur aus CAPTION und nem Rand darunter, aber nicht darüber.

    MfG


Anmelden zum Antworten