On Windows (Vista32), I want to display some simple graphics on top of a fullscreen flash window (an overlay of useful information while using the flash application). What's the fastest way to accomplish it?
I think I may be able to achieve it using DirectX with the DDSCAPS_OVERLAY flag but with the only example I've found I get an exception:
E_NOTIMPL
The function called is not supported at this time
on
m_direct_draw->CreateSurface(&ddsd, &m_overlay_surface, 0)
(full code here: http://nexe.gamedev.net/files/Overlay-2005-11-21.zip)
Something relevant to C/++ or Python would help me. I'm using the latest DirectX SDK.
Thank you
Just create a Layered Window and draw to it with an alpha channel - in WPF, this is as easy as setting the AllowsTransparency bit on the Window
While the transparent layered window is useful, it doesn't appear on top of the fullscreen flash with WS_EX_TOPMOST set.
Note sure how to reply to Paul sadly.
Overlaying on a 3D fullscreen application is very relevant but while it works and flash appears to load dx9, it doesn't show on flash.
Related
For an accessibility desktop application I must overlay the desktop screen with numbers, text and a grid of rectangles (stroked with e.g. red brush).
Ideally this should work on any window manager system (windows, linux KDE/GNOME, possibly even mac).
What is the standard approach to something like this? I was thinking of taking a screenshot of the screen and then drawing on top of it but I'm unsure on what to use to draw.
There is a library that could help you out in making cross-platform applications. glfw, this is capable of making an application window for windows, mac, Linux, and more.
For the graphics stuff, you could use OpenGL or Vulkan(personally not advised for new users) graphics APIs which are cross-platformed. I was thinking of taking a screenshot of the screen and then drawing on top of it but I'm unsure on what to use to draw. For this you could you framebuffers, learning OpenGL.
I'm making a non-rectangular dialog, modelled over an image from Photoshop (the image is the background of the dialog, and the user will see trough the transparent part of the image). I'ts like a dashboard-style window for a media-app with a few custom-drawn controls. Most of the background-image is either opaque or 100% transparent - but in between there is a thin area of partially transparent pixels, ment to blend the image smootly into the background. This works great for web-graphics, but I have not found a way to make this work for Windows windows. I'm using the Windows Template Library (WTL), msvc 2008 - and the app must run on Windows XP as well as Vista and Windows 7.
Currently, I'm simply using the opaque part of the background-image to create a GDI clipping-region, but this gives pretty rough edges.
Does anyone know about any API functions to accomplish this (part of WTL, or reachable from WTL)?
Perhaps you could use layered windows? I haven't tested these with WTL but you should be able to get the effect you want. To the best of my knowledge I don't think you can add controls to a layered window so you'll need to attach it to another (non-layered) window to use controls.
Not sure how this interoperates with WTL, but have a look at the AlphaBlend function. You'll need to select your partially transparent bitmap into a DC and copy that to your dialog's DC in your paint function.
This article shows how to use layered windows with WTL and the Gdi+ API which is available on all your target platforms.
In our MDI application - which is written in MFC - we have a function to save a screenshot of the MDI client area to file. We are currently doing a BitBlt from the screen into a bitmap, which is then saved. The problem is that some of the MDI child windows have their content rendered by OpenGL, and in the destination bitmap these areas show up as blank or garbled.
I have considered some alternatives:
- Extract the OpenGL content directly (using glReadPixels), and draw this to the relevant portions of the screen bitmap.
- Simulate an ALT+PrtScr, since doing this manually seems to get the content just fine. This will trash the clipboard content, though.
- Try working with the DWM. Appart from Vista and Win7, this also needs to work on Win2000 and XP, so this probably isn't the way to go.
Any input will be appreciated!
The best way to get a bitmap from an OpenGL window is to draw the content to a bitmap 'window'. See PFD_DRAW_TO_BITMAP for more information on how to do this.
If you want to go with the Alt+PrtScr way, you have to consider that many users have their own print screen tool installed which reacts on that very same hotkey. So you can't be sure that this hotkey will copy the content to the clipboard. It may just open the window of the installed print screen tool/utility.
Use the glReadPixels() approach. This question is asked quite often, here, on the gamedev.net forums and on other places, so google should show you code samples easily, but the glReadPixels() approach is the generally recommended approach.
Simulating keypresses is a recipe for disaster, I would stay away from that.
I have an application with an OpenGL window as a child window of the main window.
When I display a dialog box above the OpenGL window, it doesn't get drawn. It's like it's not getting WM_PAINT messages. If I can guess the title bar position of the dialog box, I can drag it and it's still responsive.
I realise this might be a vague question, but I was wondering if anyone else has seen this sort of behaviour before and knew of a solution?
I wondered if the Pixel Format Descriptor would make a difference - I had PFD_DRAW_TO_WINDOW, but changing to PDF_DRAW_TO_BITMAP didn't make any difference. I'm not sure what else I should be looking at?
Bugger. Should have given all the details. I was running Windows in a virtual machine on Mac OS X using Parallels. I upgrade from Parallels 3 to 4 and now everything is working fine. I suspect a Parallels video driver issue.
Thanks to all those who answered with suggestions.
Is your opengl window constantly rendering. It is possible that the 3D hardware is simply rendering into an overlay that is overdrawing your dialog box. If you position the dialog box so it overlaps your main window, can you see some of it?
Try to pause rendering into the main display to see if it effects the results.
You will also need to make sure that your window style ensures the results are clipped...
cs.style |= WS_CLIPSIBLINGS | WS_CLIPCHILDREN ;
You should check though all the items mentioned in this MSDN article, as it covers a lot of the basics for getting opengl rendering in a window correctly.
http://msdn.microsoft.com/en-us/library/ms970745.aspx
You may need to switch overlay off. It can be done via forcing back buffer presenting method to copy instead of swap.
Use wglChoosePixelFormatARB and one of parameters should be
WGL_SWAP_METHOD_ARB with value WGL_SWAP_COPY_ARB
This may seems stupid but are you sure your OpenGL window is not flagged "topmost" ?
Does the dialog box disappear also behind borders of your window or just behind the OpenGL rendering rectangle ?
I have a C++ application that uses the Win32 API for Windows, and I'm having a problem with GDI+ dithering, when I don't know why it should be.
I have a custom control (custom window). When I receive the WM_PAINT message, I draw some Polygons using FillPolygon on a Graphics device. This Graphics device was created using the HDC from BeginPaint.
When the polygons appear on the screen, though, they are dithered instead of transparent, and only seem to show few colors (maybe 256?) When I do the same thing in C# using the .NET interface into GDI+, it works fine, which is leaving me wondering what's going on.
I'm not doing anything special, this is a simple example that should work fine, as far as I know. Am I doing something wrong?
Edit: Nevermind. It only happens over Remote Desktop, even though the C# example doesnt Dither over remote desktop. Remote Desktop is set at 32-bit color, so I don't know what's up with that.
Hmm... The filling capabilities are determined by the target device. When working over remote desktop, AFAIK Windows substitutes the display driver, so that can change the supported features of the display.
when drawing on wm_paint, you actually draw directly on the screen surface, while .net usually uses double buffering (draws to in memory bitmap and then blits the entire bitmap)
there are some settings in gdi+ that affect the drawing quality. maybe there are different defaults for on-screen, off-screen and remote painting?
It only happens over Remote Desktop
Many remoting applications will reduce colour depth in order to reduce bandwidth requirements. While I haven't used Remote Desktop, the same happens on certain VNC connections. I'd check your RD server and client settings.