PDA

View Full Version : Using standard controls in fullscreen mode



Gadget
13-01-2003, 06:19 PM
How can I use standard controls in fullscreen mode? The controls occupy the top 1/5 of the form only. When I flip, the images are obviously lost as I am displaying the empty back surface. The controls still work, but they aren't painted... Any ideas? There must be a way, I have seen it done!

Thanks

Clootie
13-01-2003, 10:15 PM
In DirectX7 use FlipToGDISurface
In DirectX8, DirectX9 the only "easy" solution is to use screensize borderless stay-on-top window and render in windowed mode.
Both in DirectX9 you can "paint" windows controls (one by one) each frame on Direct3D textures or back buffer via their GetDC method. In DirectX8 only solution is to paint in off-sceen bitmap lock it and manually transfer it's data to DirectX8 texture/back buffer.

Gadget
14-01-2003, 01:20 PM
Thanks for the reply! Not sure how I can use FlipToGDISurface? I have drawn to the back surface and flipped it, and the components vanish, I can get them back using FlipToGDISurface, but I need the components to appear on both surfaces? Or maybe just flip part of the screen? Is that possible?

I need to use a TRichEdit in DirectX, this is really frustrating...

Clootie
14-01-2003, 07:46 PM
From DirectX 7 SDK Help:

hWndDlg = CreateDialog(g_hInstance,
MAKEINTRESOURCE(IDD_DIALOG_SAMPLE),
hWnd, (DLGPROC) SampleDlgProc);
ShowWindow(hWndDlg, SW_SHOWNORMAL);
Of course, at this point the dialog box is shown only on the hidden GDI surface. It does not appear on the primary surface, which is controlled by DirectDraw.

If the hardware capabilities include DDCAPS2_CANRENDERWINDOWED (see DDCAPS), displaying and updating the dialog box is easy. The application simply calls the IDirectDraw7::FlipToGDISurface method, which makes the GDI surface the primary surface. From now on, all updates to the dialog box will be displayed automatically, because GDI is now rendering directly to the front buffer. The application continues rendering to the back buffer, and on each pass through the rendering loop the contents of the back buffer are blitted to the front buffer by DirectDraw. The dialog box is not overwritten because the front buffer is clipped to the application window, and the dialog box is obscuring part of that window.

The following code, from the FSWindow_Init function, creates the clipper, associates it with the application window, and brings the GDI surface to the front:

if (ddObject->CreateClipper(0, &ddClipper, NULL) == DD_OK)
ddClipper->SetHWnd(0, hwndAppWindow);
ddObject->FlipToGDISurface();
Then, in the FSWindow_Update function, the following code blits the rendered contents of the back buffer to the clipping region:

ddFrontBuffer->SetClipper(ddClipper);
ddFrontBuffer->Blt(NULL, ddBackBuffer, NULL, DDBLT_WAIT, NULL);

Gadget
15-01-2003, 07:48 PM
Thanks for the replies :) It's nice that some one is prepared to help beginners ;)

I have put FlipToGDISurface to work now and it does what I want, which is to restore the GDI surface. But...

The back buffer needs the component I am using blitting to it before I flip. (not using windowed mode btw)

I have just added this code before the flip, and it just ends the app? no errors? If I remove it, I can happily flip the surface...

What am I doing wrong?

g_pDDSBack.GetDC(dxHDC);
BitBlt(dxHDC,0,0,redtMessages.Width,redtMessages.H eight,frmMain.Canvas.Handle,redtMessages.Left,redt Messages.Top,SRCCOPY);
g_pDDSBack.ReleaseDC(dxHDC);

Thanks

Gadget
15-01-2003, 09:28 PM
It's OK I found a much easier solution... Blitted from the primary to the back buffer.

The only thing I need to know now is how to form an efficient loop...

Where is the best place to launch the loop from? App.OnIdle? Can I optimize the message processing bit of the application? I need to capture keystrokes still, allow paint messages, and I am using Indy TCP/IP components. Any advice? I am getting 30 fps at the moment.

EDIT: One important problem... When you use the scroll bar of the TRichEdit it halts the processing of the loop... Can I get around this?

Clootie
15-01-2003, 09:41 PM
Application Just halts?
Have you tried to comment BitBlt line and leave just GetDC/ReleaseDX sequence and see what will happen?
Or have you tried to run it without Delphi debugger attached?

Upps, it seems to late ;-)

Ok. "Where to place the loop" is already discussed somethere on these forums lately. In your case of [holding] scroll bars of TRichEdit the only solution seems to be create a separate thread and render from it - but it's dangerous!