Jump to content
  • Advertisement
Sign in to follow this  
zethon

Direct3D & Windows Common Controls

This topic is 4861 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I'm fairly new to DirectX but not at all new to Win32. I'd like to use a regular windows common control on my Direct3D surface. I can use CreateWindowEx just fine to create my control, but I can't figure out how to get my Direct3D scene to stop rendering over top of it. How can this be done? I was thinking that maybe I could have the part of the screen where the common control (an edit box) is not be rendered. In Win32/MFC there are regions which you can define not to be drawn -- is there any such thing in DirectX? Or is there a better way to do this? Thanks!

Share this post


Link to post
Share on other sites
Advertisement
I haven't done this before, but maybe you could just call the paint method for the control at the end of your render frame, after you call Present. You would have to know for sure that the Present call updated the screen, so it may not work with swap chains. It may not work at all. You could define an extra viewport and not render anything to it.

Share this post


Link to post
Share on other sites
I think it is done with scissors, SetScissorRect and such.

Alternatively, you could use a 3 phase rendering: (not tested, just an idea)
0. Clear window with Z-Buffer enabled.
1. Draw rectangles with a Z value that is lower than any
Z value of your geometry, positioned where the simple gdi controls are (x,y,dx,dy)
(in a way that they overlapp each other).
2. Draw the gdi controls.
3. Draw the whole scene normally. (since the rest of the scene would appear "behind" the drawn directx rectangles).
Flickering should be expected though with this technique.

If you could make use of custom draw gdi control and render the content to a memory context, you could use that data to blit in the directx on a surface,
avoiding flickering.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Thank you for the replies. I've tried a few of the solutions, as far as making sure the WM_PAINT message is sent after my Present() call and have even tried using scissors to cut the region, but I'm still having not luck.

I know that in the Oct 2005 DirectX SDK there are a set of common controls that come with it. Unfortunately I cannot use that SDK. Is there no set of DirectX common controls that can be used with older SDKs?

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
I know that in the Oct 2005 DirectX SDK there are a set of common controls that come with it. Unfortunately I cannot use that SDK. Is there no set of DirectX common controls that can be used with older SDKs?

Unfortunately not. Most games implement their own User Interface. It is problematic trying to use the standard Windows controls in a D3D application. The DX SDK implemented a set of its own controls but if you take a close look at the implementation, you'll notice that they're not using Windows controls at all. Everything is implemented from scratch.

I think there are a couple of open-source GUI libraries out there you could use. Or you could try to port the GUI components from the current SDK to whichever SDK version you're using.

neneboricua

Share this post


Link to post
Share on other sites
I am not aware of any controls other than those
being shipped right from the beginning of the DirectX 9 SDK,
those that are directx-enabled so to speak (build on top of directx).

What about my composite solution with the zbuffer?
It has pretty good chances of working.

Share this post


Link to post
Share on other sites
Quote:
What about my composite solution with the zbuffer?
It has pretty good chances of working.


I've been fooling around with DirectX for about a week now, so a good portion of what you wrote in the zbuffer solution is Greek to me. :) I will play around with it though and see what I can do.



Share this post


Link to post
Share on other sites
Ok, so here's the layman's terms.

0. Create a device with ZBuffer and enable ZBuffering.

1. Create coupled triangles to form rectangles, using the untransformed vertex
coordinates. Make sure the rectangles match on the screen the gdi controls (if you would only draw the rectangle it would hide a control, a button for example = each rectangle is on top of a gdi control) AND that their Z values are as close to the directx camera view point as possible (0.0f for example).

2. Clear the scene with a contrasting color (I suggest 0xff00ff), and with a Z depth of 1.0f.

3. Render the triangles that make the rectangles that hide the gdi controls.

4. Draw the gdi controls.

5. Render the rest of the scene.

6. Present scene.

The fact that the rectangles have a small Z than the rest of the scene makes that the rest of the scene, when rendered, to not modify whatever data already exists inside the rectangles. Which would be the rectangle's color/texture, if
it were not for the drawing of the gdi controls. Ah, and force only the drawing of the controls, not their background, by posting WM_PAINT messages to them. Otherwise the whole window would flicker.

Hope this helps.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Thank you for the replies. I've tried a few of the solutions, as far as making sure the WM_PAINT message is sent after my Present() call and have even tried using scissors to cut the region, but I'm still having not luck.


There is not guarantee that things are actually presented when you call Present. It just queues a request to Present, similar to how the WM_PAIN message is a queued request to repaint.

Something to try:
Create your device with a locable backbuffer.

Message Loop:
BeginScene
DrawD3D Stuff
EndScene
Present
Lock the BackBuffer
Send WM_Paint
Process all pending windows messages

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!