When I run a fullscreen window (C++ with SDL using the SDL_FULLSCREEN flag), alt-tab has no effect. Researching it, I only found posts of people having problems with it. Is there a way to do it consistently across different machines? (I'm running Ubuntu now, but I'd like portability) Does OpenGL handle this better? (considering switching)
SDL likes to XGrabKeyboard() when fullscreened on X11. This tends to lock out your window manager's hotkeys.
Fix SDL or fix your window manager.
Related
In GLFW, you can tell a window to go fullscreen on a particular monitor when you create it, but is there any way to make it stretch across multiple monitors?
On most platforms, what you are asking for is not really possible using a framework as portable as GLFW.
Fullscreen modes generally fill one logical display. You need something lower-level to setup multi-monitor topologies (AMD and NV have entire APIs and driver settings for this).
You can stretch a window across multiple monitors though and using the DECORATED flag (specifically turning it off), you may be able to make this window spanning multiple monitors appear to be fullscreen (e.g. no border / title bar). Hiding the taskbar (Windows) / launcher/menu (OS X) is another matter though.
For a while I've been using SDL to write my 3D engine,and have recently been implementing an editor that can export an optimized format for the type of engine Im building. Right now the editor is fairly simple, objects can just be moved around and their textures and models can be changed. As of right now, I'm using SDL with OpenGL to render everything, but I want to use Qt for the GUI part of the editor, that way it looks native on every platform. I've got it working great so far, I'm running a QApplication inside of the SDL application, so it basically just opens 2 windows, one that uses SDL and OpenGL, and the other using Qt. Doing a bit of research, I've found that you can manually update a QApplication, which totally removes any threading problems, and everything works. Just in case you're having a hard time visualizing this, heres a picture:
What my goal is to merge these windows into one, because on smaller screens (like my laptop's) it makes it really hard to keep track of all the different windows that I would eventually have. I know theres a way to render to Qt with OpenGL, but can this be integrated with SDL? Am I going to need to move away from using an SDL window and use a QT one if the editor is enabled? Just to clarify, when the engine isn't in editor mode, it won't use and Qt, just SDL, so optimally I wouldn't need to do this.
Drop the SDL part. You have Qt, which does everything SDL does as well. Just subclass a QGLWidget and use that.
You can keep your game and editor separate processes and still make them part of the same app.
Just spawn the window where you want the game to run as part of Qt, and at least in windows, you can then pass the window handle to your game, and make sure when your game is setting up, instead of creating the window yourself in SDL and binding the opengl context to it, you can actually bind to the existing handle.
There are some gotchas with this technique to watch out for such as input focus I believe (I tested with directX, but it might be similar with SDL). The problem is that the foreground mode does some dumb checks on the "root" window which for me was not the window that owned the opengl context, so it failed to initialize. However background mode worked. I think that was for a joystick now that I think about it, but anyway, that's how you can merge everything together.
My application uses Gtkmm and gtkglextmm. It loads pictures form HDD and shows them using OpenGL capabilities. However when I (for example) resize mainwindow some parts of GUI goes black and I don't know why. On Ubuntu this problem doesn't exist.
Here is a video illustrating what I am talking about: http://youtu.be/XGNJmddh_m4
Without seeing your code, and assuming it does nothing arcane I'd attribute this to some bug in the GTK+ port for Windows itself. I suspect the doublebuffering built into GTK+ getting tangles up with the inherent doublebuffering of the composition process (Aero), and having a set a background erasure brush in the WNDCLASSEX of the windows GTK+ creates.
I'd file this as a bug with GTK+
Came across a problem which google searches could not help me with. I have a little SDL application that runs at 60 fps. Everything is working fine, however, it pauses/stops running when the window is dragged ( 640 X 480 window ). Is there a flag or something that can be set in the SDL window to prevent this from happening? Or is this unavoidable?
Windows uses a modal event loop for dragging windows, which blocks your main UI thread.
More discussion (and suggested workarounds, such as drawing from a second thread): http://www.sfml-dev.org/forum/viewtopic.php?p=8384&sid=632116a07a569edee43331076e028071
OpenTk apparently has code designed to address this, maybe you can reuse some of it: http://www.opentk.com/node/1218
I was wondering if there was an OpenGL command to return control to Windows when the window the rendering is happening in is no longer the focus. As it stands, the mouse is constantly moved to the center of the screen even when it is not the focus.
Any way around this?
Thanks!
OpenGL is a rendering API; it does not have commands that deal with the underlying windowing system. WGL, GLX, and Apples AGL do that sort of thing. And even those APIs don't deal with mouse movement.
If the mouse is being forced to the center of the screen by your application, then it is probably due to some other code that you are using. Many of the common tools for creating OpenGL windows (FreeGLUT, GLFW, Qt, wxWidgets, etc) have commands for capturing the mouse and affecting its position. You will need to check your code and the documentation of whatever software you're using to interface with your window to see where the problem lies.
For windows, make sure you're setting mouse position if windows is active.
if(getactivewindow() == this->hwnd)
setmousepos()
This is probably the issue.