When you make a window in glut using glutCreateWindow it puts a top to the window? What if I want to do some OpenGL rendering without a window top?
This probably doesn't make much sense without a picture:
Essentially I want to remove this from the window.
Use GLUT_BORDERLESS and GLUT_CAPTIONLESS as additional parameters to the glutInitDisplayMode() to get rid of window border and caption as follow:
glutInitDisplayMode(GLUT_RGBA|GLUT_DOUBLE|GLUT_DEPTH|GLUT_BORDERLESS|GLUT_CAPTIONLESS);
At least it works pretty good with freeglut 2.8.1 on Windows.
The proper terminology for what you want is "undecorated window" or "borderless window". Unfortunately, I can't find any GLUT calls which let you control window decorations.
The closest I was able to find was glutFullScreen which, on X11 platforms, is often implemented by maximizing an undecorated window... but it'll re-decorate it if you un-maximize it.
This forum thread seems to confirm my conclusions.
Related
Hello people of the internet, I was just wondering is it possible to create a window using CreateWindow and also making is completely transparent? This includes the top bar (where the close and minimize buttons are located, idk what its called) and window it self. So the entire "application" I need to be transparent. If you could help that would be amazing, have a great rest of your day/night!
I was looking at Creating a transparent window in C++ Win32, but it did not work how i wanted it and is very outdated.
I'm trying to figure out how to create a graphical interface, in X11, which exists outside of a window manager's/desktop environment's standard window frame. For example, when Thunderbird finds new mail, it shows a special alert in the lower right hand corner of the screen which is shown without any frame (no close/minimize buttons, etc.).
I'm specifically interested in doing this in QT with C++, but if someone knows a solution with a different graphical library, that would be helpful too.
For QT pass Qt::FramelessWindowHint as a window flag when you construct your top level widget.
See here for more info:
http://doc.qt.nokia.com/main-snapshot/qt.html#WindowType-enum
You can do this with X as well although I haven't done so in a long time.
http://www.xfree86.org/current/XCreateWindow.3.html
With GTK you would use gtk_window_set_decorated(), which would probably be Gtk::Widget->set_decorated() (I think, I don't use gtkmm).
http://developer.gnome.org/gtkmm/unstable/classGtk_1_1Window.html#a67adb1d8051a38e0e5272f141bb8778c
I've seen things like this and I was wondering if this was possible, say I run my application
and it will show the render on whatever is below it.
So basically, rendering on the screen without a window.
Possible or a lie?
Note: Want to do this on windows and in c++.
It is possible to use your application to draw on other application's windows. Once you have found the window you want, you have it's HWND, you can then use it just like it was your own window for the purposes of drawing. But since that window doesn't know you have done this, it will probably mess up whatever you have drawn on it when it tries to redraw itself.
There are some very complicated ways of getting around this, some of them involve using windows "hooks" to intercept drawing messages to that window so you know when it has redrawn so that you can do your redrawing as well.
Another option is to use clipping regions on a window. This can allow you to give your window an unusual shape, and have everything behind it still look correct.
There are also ways to take over drawing of the desktop background window, and you can actually run an application that draws animations and stuff on the desktop background (while the desktop is still usable). At least, this was possible up through XP, not sure if it has changed in Vista/Win7.
Unfortunately, all of these options are too very complex to go in depth without more information on what you are trying to do.
You can use GetDesktopWindow(), to get the HWND of the desktop. But as a previous answer says (SoapBox), be careful, you may mess up the desktop because the OS expects that it owns it.
I wrote an open source project a few years ago to achieve this on the desktop background. It's called Uberdash. If you follow the window hierarchy, the desktop is just a window in a sort of "background" container. Then there is a main container and a front container. The front container is how windows become full screen or "always on top." You may be able to use Aero composition to render a window with alpha in the front container, but you will need to pass events on to the lower windows. It won't be pretty.
Also, there's a technology in some video cards called overlays/underlays. You used to be able to render directly to an overlay. Your GPU would apply it directly, with no interference to main memory. So even if you took a screen capture, your overlay/underlay would not show up in the screen cap. Unfortunately MS banned that technology in Vista...
I'm coding a short game in C++ and Win32, and I want to be able to make it in fullscreen with a fixed size. I also want the user to be able to switch focus between the game window and other windows as much as he/she wants without any weird screen glitches.
So far I know of the ChangeDisplaySettings function and creating the window with the WS_POPUP style at initialization to make it fullscreen. To detect the user switching focus to other windows by way of alt+tab or otherwise, what messages should I be handling on the window's WndProc or should I be using another function? When loss of focus is detected should I only call ChangeDisplaySettings(NULL, 0); or are there other functions I should call as well? And what method should I use to handle focus back into the window?
Also can anyone give me some info on how to make it work smoothly for different screen sizes?
Thanks for any help.
If you want an exclusive full screen window, use DirectX.
But I don't recommend it. Changing the display mode causes glitches, rearranges the users icons and so on. Whether done by you, or Direct X.
Rather create a normal window at your native res, and let the user maximize it if wanted.
You could also use the GDI+ library of Windows XP (and newer) to use hardware-accelerated stretching (draw in 640x480, let GDI+ resize it to the native resolution). Then you don't need exclusive mode of DirectDraw nor ChangeDisplaySettings.
Also drawing into a 640x480 big background buffer and bit blitting it on the drawing surface via StretchBlt can be a performant solution.
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 ?