I'm new to openGL and SDL and I'm having some problems with a basic program I wrote. I've narrowed it down and it seems like the problem is a conflict between the SDL_CreateRenderer function and how SDL manages OpenGL.
Basically the program is a simple game, drawn with OpenGL, and the problem has risen with me creating a menu. Since the game window was created with the "SDL_WINDOW_OPENGL" flag, I created another window for the menu. Whenever I need to switch between game and menu I just hide and show whichever window I need. To draw on the menu window though I need to create a renderer but after doing so, if I try to go back to the OpenGL window everything crashes catastrophically (computer slows down, everything is unresponsive...).
Can anyone guess where the problem could lie? Or can anyone suggest a better way to solve my game-menu problem?
Don't try to inter-op OpenGL and SDL_Renderer: even if you could guarantee that your platform did/did not implement SDL_Renderer in terms of OpenGL the SDL_Renderer API doesn't have any way to properly set/restore the OpenGL state that SDL_Renderer uses.
Related
I am looking for some information about rendering child windows in specific about how OpenGL interop with GDI. The problem that I have is that I have basically is that I have two windows, first, the main windows are created in qt, and inside of qt, a child window is hosted that leverages an OpenGL renderer.
Now what I wanted to do is to host an overlay on top of my OpenGL window, so I use that to overlay the OpenGL window. The problem that I am having is that when I render with OpenGL, the OpenGL generated graphics seem to obscure the graphics area including and effectively undo the graphics composited by qt.
In the image below the blue area is the qt overlay, in that picture I'm using GDI (BeginPaint/EndPaint) so and the windows seem to interact fine. That is, window order seems correct, the client region is correct. The moment I start to render with Opengl the blue area gets replaced with whatever OpenGL renders.
What I did I basically created to create the overlay I created a second frameless, topmost QMainWindow, and once the platform HWND was initialized I reparent it. Basically I change the new windows parent to be the same parent of my OpenGL window.
What I believed this would do is that the every window, gets drawn separately and the desktop composition manager would make the final composition and basically avoiding the infamous airspace problem as documented by Microsoft in their WPF framework.
What I would like to know is what could cause these issues? At this point, I lack understanding why once i render with OpenGL the pixels by qt overlay are obscured, even though windows hierarchy should say make them composited. What could I do to accomplish what I want?
Mixing OpenGL and GDI drawing on a shared drawable (that also includes sibling / childwindows without the CS_OWNDC windowclass style flag) never was supported. That's not something about Qt, but simply how OpenGL and GDI interact.
But the more important issue is: Why the hell aren't you using the OpenGL support built right into Qt in the first place? Ever since Qt-5 – if available – uses OpenGL to draw everything (all the UI elements). Qt-5 makes it trivial to mix Qt stuff and OpenGL drawing.
I was looking at how sometimes when you right click, the menu goes outside of the window.
Is this implemented with a separate window? If so, how can I get this functionality. I am trying to use GLFW, but I understand if it isn't possible.
Currently I am on windows, but I like keeping my options open, which is why GLFW would be preferable.
I noticed that GLUT has such a feature. If you are confused to what I am looking at then look at that.
Thanks for any help!!
Overlapping menus (in MS Windows) have to be implemented as a new top-level window, you would have a new OpenGL rendering context and draw the menu in that space - yes, it's a fair bit of work all for the edge-case of a menu overspilling the parent window,
However this isn't often a problem in OpenGL programming because if you're working on a full-screen game then the menu will always be displayed within the main window, and even if it isn't a full-screen a game your users really won't notice them as games tend to use different UI concepts like radial-menus which wouldn't overspill the parent window.
Or if you're working on a non-game title, chances are it isn't full-screen and is going to be an OpenGL rendering area within a larger application that is rendered using a native UI toolkit (e.g. 3ds Max, AutoCAD, etc), in which case no problem: just use native menus.
You can, of course, use native menus in an OpenGL application anyway, provided you do the necessary plumbing for native window messages.
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.
In my opengl project, i need to create some children of opengl window to get some UserInterface to the user and opengl to make some graphic in my program, and actually i have been successfully to make it all.. but the problem is: where we are going to move or resize the child window, my opengl background is getting fall appart yet when resizing and moving are done, my opengl background back to normal.
if it possible, could you explain me step by step to do it?
what should i do to solve this case?
I just recently changed all rendering in my application/game from SDL to OpenGL. I still use SDL for keyboard input, loading images and creating the window.
But since i only render in OpenGL do you think that i should change the window to a OpenGL initialized window instead of a SDL window. The header i use for OpenGL functions at the moment is "SDL_opengl.h". Does that affect things?
What are the advantages and disadvantages if i do this? Right now it feels like it's the logical "next step" since i got rid of all other SDL rendering code.
Just keep on using SDL for input and window management.
There's no provision for either in the OpenGL spec so there's really no such thing as an "OpenGL initialized window".
As genpfault said, you should keep using SDL for your window initialization. It's more clean and portable than OS-specific methods of initializing a window for OpenGL rendering.
I would also recommend switching from SDL_opengl.h to SDL.h and gl.h; the definitions in SDL_opengl.h aren't necessary for basic window management, and they conflict with the definitions in other OpenGL libraries like GLEW (which you may want to use later for pixel shaders and framebuffers).