I'm currently developing an application with OpenCV to do visual recognition of elements on the screen.
While a visual representation of the process is not needed, it would be very useful for debugging purposes if I could find a way to draw circles, lines and possibly text directly on the screen, without having an app window.
There are certain applications that, for instance, draw HUDs over the screen. How do they go about doing that?
I need a way for my drawing to always be at the front. In general, all the ways I managed to find involve painting on a window (WinAPI, Direct2D, OpenGL). Is there a workaround to make it appear like it's simply a layover on the desktop (including all open windows)?
for the purpose of debugging, just literally draw on the screen. IIRC GetDC(0) will get you a device context for the screen, but check out that whole family of functions. in Windows 7 it doesn't even foul up other applications' displays, and reportedly it's likewise "safe" on the mac.
for example, this draws an ellipse in the upper left of the screen:
#include <windows.h>
int main()
{
HDC const dc = GetDC( 0 );
Ellipse( dc, 10, 10, 200, 200 );
}
the graphic disappears if it's on top of a window and that window is moved.
You can achieve the device context (DC) of the screen, and draw in that DC as usual. The output will be directed to the screen. To achieve that, call WinApi GetDC("DISPLAY"), if i'm not mistaken.
Related
I'm trying to create an game / application using GLFW and OpenGL 3.3. I'd like to be able to detect collision with the sides of the window, but it seems that the drawable area of the window differs from the size of the window set using glfwCreateWindow().
So my question is, how do I get that drawable area, ie. the size of the window minus the border? I'd rather not have to use the WinAPI so as to make it more cross-platform, and glfwGetWindowFrameSize() is in GLFW 3.1, which isn't completed yet.
Edit: My question makes it seem like I need to use GLFW do accomplish this, which isn't true. I just wanted to note that I'm using GLFW as a window / input handler.
You want glfwGetFramebufferSize.
glfwGetVideoMode returns the video mode of the specified monitor, not the size of your window. For fullscreen windows, they happen to be the same, but for other windows they are likely to be very different.
From the looks of it, you do not need to know the size of the window, I'm assuming in pixels? If you want to do collision detection with the border of the window, you just need to detect the the NDC of your vertex, and once it reaches x or y = (-1, 1) then you would've had a collision. Nonetheless, if you want to get the size in pixels of your OpenGL context then use glfwGetVideoMode().
I am trying to make an interesting tutorial for a program I have developed, and I want arrows to appear and disappear on the screen at certain times of the tutorial. These arrows I have already drawn on paint (I can have them in png, jpg... practically any image format), but I have on idea on how to make them appear on the screen and disappear when I want them to.
Basically if they could appear on the screen, like on top of any other window, on the highest layer (with only the mouse itself capable of going over it), that would be my ideal code. It would not matter if print screen would include the image or not, all that matters is that it can appear and disappear when the right code is given.
Any help at all would leave me in your eternal debt xD!
Probably the easiest way to do this is to create a see-through and click-through fullscreen window that is always on top. Then you can draw the arrows in this window with GDI (assuming you're targeting Windows) at any position on-screen you like.
The window can be made see-through and click-through by using
WS_EX_LAYERED | WS_EX_TRANSPARENT
as extended window style.
Many laptops nowadays have FN hot keys to change volume, brightness, etc. and usually display a visual cue that is rendered on the screen completely above the operating system. For new Windows 8/8.1 systems this visual even appears outside of the desktop in the metro side. They cannot be drawing inside of a borderless window otherwise it wouldn't show up over the metro interface.
I have tried researching whether DirectX can draw directly to the screen but it doesn't appear it can. I don't even know if I should look into OpenGL... ?
I had some success using GDI; specifically the GetDC function with the parameter NULL to grab the screen device.
#include <Windows.h>
int main() {
const HDC dc = GetDC(NULL);
while (1) {
Rectangle(dc, 100, 100, 500, 500);
}
}
However, this requires re-rendering everything repeatedly because my region of the screen can be overwritten by other windows changing in the background. And even with it re-rendering in a loop, there is massive screen flicker.
How do the OEM manufacturers of these laptops achieve this?
Thanks.
It looks like these are borderless windows.
For example, have a look at the task switcher window:
Related question:
Windows 8 Layered Windows Over Metro Apps
If you want a window on top of Metro, you need it to declare accessibility.
I'm trying to draw on the screen (the whole screen, on top of every other window) using GDI+.
I've passed NULL to GetDC to get a HDC to the screen, and then used that to create a Graphics object, and used DrawRectangle to draw rectangles on the screen.
Everything works..except...the inside of the rectangle won't update.
Like if I draw it over a command prompt, and move the command prompt, the inside of the rectangle remains black.
I expect to see whats under the rectangle.
Here's the code that's doing the drawing..
Pen BluePen(Color(255, 0, 255, 0), 2);
Graphics graphics(screenDC);
graphics.DrawRectangle(&BluePen, myRect);
Pretty simple, so is there something I have to do to get the inside of the rectangle to update when the screen does? Or to get it truely transparent.
================= EDIT =================
Well I had given up on this, and assumed it wasn't possible, until...I realized the Inspect tool that comes with the Windows SDK does this perfectly.
I would like to recreate something similar to the highlight rectangle, and if I select a window (such as Firefox) and then bring Inspect into focus I can move it around freely with everything being updated perfectly.
There's not even any flickering.
So...does anyone know how Inspect manages to do this?
Also answers in GDI instead of GDI+ are fine...
In windows the screen (and the windows ...) surface(s) are ... volatile, like sandboxes. The "overlapping" of windows and the re-painting of uncovered surfaces is an illusion made by proper event management.
Everything is drawn remain there until something else is drawn over it.
"Uncovering" a surface makes the window representing that surface to receive a WM_PAINT message. It's up to that window procedure to react to that message by re-painting everything is supposed to be under it.
Now, unless you intercept somehow the WM_PAINT message that is sent to the desktop window, you have mostly no chance to know the desktop needs a repaint and hence your paint code will not be called and no repaint will happen. Or better it happens following just the desktop window updating code, that's not aware of your paint.
What is the best way to draw things in the Console Window on the Win 32 platform using C++?
I know that you can draw simple art using symbols but is there a way of doing something more complex like circles or even bitmaps?
Yes, it is possible.
Get the HWND of the console window using GetConsoleWindow and then draw in it.
#define _WIN32_WINNT 0x601
#include <windows.h>
#include <stdio.h>
int main() {
// Get window handle to console, and device context
HWND console_handle = GetConsoleWindow();
HDC device_context = GetDC(console_handle);
//Here's a 5 pixels wide RED line [from initial 0,0] to 300,300
HPEN pen = CreatePen(PS_SOLID, 5, RGB(255, 0, 0));
SelectObject(device_context, pen);
LineTo(device_context, 300, 300);
ReleaseDC(console_handle, device_context);
getchar();
return 0;
}
Note: GetConsoleWindow was introduced in Windows 2000. It's available when _WIN32_WINNT is set to 0x500 or greater.
No you can't just do that because Win32 console doesn't support those methods. You can however use GDI to draw on the console window.
This is a great example of drawing a bitmap on a console by creating a child window on it:
http://www.daniweb.com/code/snippet216431.html
And this tells you how to draw lines and circles:
http://www.daniweb.com/code/snippet216430.html
This isn't really drawing in the console though. This is sort of drawing "over" the console but it still does the trick pretty well.
It is possible, albeit totally undocumented, to create a console screen buffer that uses an HBITMAP that is shared between the console window process and the calling process. This is the approach that NTVDM takes to display graphics once a DOS application switches to graphics mode.
See it.
As Nick Brooks has pointed out, you can use GDI calls in console apps, but the graphics cannot appear in the same window as the text console I/O. This may not matter since you can draw text elements in GDI.
A simplified interface to GDI calls in console apps is provided by WinBGIm. It is a clone of Borland's DOS BGI API, but with extensions to handle resizable windows, mouse input, and 24bit colour models. Since it is available as source code, it also serves a good demonstration of using GDI in this way.
It is possible to either have both a console and the GDI window, or you can suppress the console window by specifying that the application is a GUI app (the -mwindows linker option in GNU toolchain) - note that specifying a GUI app really only suppresses the console, it is only really a GUI app if it has a message loop. Having the console is good for debugging, since it is where stdout and stderr are output to by default.
Not without usng ASCII art. Back in the days of DOS it was "fairly" easy to do by redesigning the character bitmaps. It might only be possible in windows by creating your own font, but im really not sure thats possible