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?
Related
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.
On screen 0, I have the mainWindow with two QOpenGLWidgets running video. On screen 1, I have another QOpenGLWidget in fullscreen mode running video. The screen 0 is a preview of what the user is seeing on the second display, which is a pair of glasses. Everything was working fine, until I added the fullscreen widget. Now only the fullscreen widget updates and the other two only update if I cause the window to repaint, e.g. moving the window.
I am a noob when it comes to opengl, but the two widgets, in the mainWindow are running together fine. So I don't believe it is the code. Is this a limitation of opengl? Qt? me?
I am using Qt5.4.
I missed an error in the console due to a lot of noise.
Requires a valid current OpenGL context.
Texture has not been destroyed
A quick search and I got my answer. I wasn't calling makeCurrent() when I was updating the texture with the next frame.
I am pretty new to openGL programming and I encountered a problem I just need some advice on. Basically I have a button which has a simple function to just print something out on the console when it is clicked and that works fine on its own. However I also have a rectangle which I use as mini window or a container to hold buttons.
The problem I have is when the button is on top of the rectangle, the clicking functions for that button isn't detected, instead the clicking functions for the rectangle which is printing a message on the console saying the rectangle was clicked, is detected. On the other hand, if I drag the rectangle away and just leave the button on its own on the window, the clicking functions will work for the button.
Is there any advice you guys can give me or tell me what to research to aid me with detecting the button click while my button is inside of the rectangle? by the way I am not using Glut on my project.
A good start would be, if you told us, how you're actually getting the user input and how you're processing it. Whatever you do, it got nothing to do with OpenGL though, because OpenGL doesn't deal with user input and OpenGL doesn't deal with scene management.
OpenGL draws things. One point, line or triangle at a time. After it pushed some pixels to the framebuffer canvas it forgets about what it just did. There's no scene in OpenGL. There are no models in OpenGL. So whatever you do, it's using something else.
I have an app that mixes OpenGL with Motif. The big main window that has OpenGL in it redraws fine. But, the sub windows sitting on top of it all go black. Specifically, just the parts of those subwindows that are right on top of the main window. Those subwindows all have just Motif code in them (except for one).
The app doesn't freeze up or dump core. Data is still flowing, and as text fields, etcetera of various subwindows get updated, those parts redraw. Dragging windows across each other or minimizing/unminimizing also trigger redraws. The timing of the "blackout" is random. I run the same 1-hour dataset every time and sometimes the blackout happens 5 minutes into the run and sometimes 30 minutes in, etc.
I went through the process of turning off sections of code until the problem stopped. Narrowed it down more and more and found it had to do with the use of the depth buffer. In other words, when I comment out the glEnable(GL_ENABLE_DEPTH_TEST), the problem goes away. So the problem seems to have something do with the use of the depth buffer.
As far as I can tell, the depth buffer is being cleared before redrawing is done, as it should. There's if-statements wrapped around the glClear calls, so I put messages in there and confirmed that the glClear of the depth buffer is indeed happening even when the blackout happens. Also, glGetError didn't return anything.
UPDATE 6/30/2014
Looks like there's still at least one person looking at this (thanks, UltraJoe). If I remember correctly, it turned out that it was sometimes swapping buffers without first defining the back buffer and drawing anything to it. It wasn't obvious to me before because it's such a long routine. There were some other minor things I had to clean-up, but I think that was the main cause.
How did you create the OpenGL window/context. Did you just get the X11 Window handle of your Motif main window and created the OpenGL context on that one? Or did you create a own subwindow within that Motif window for OpenGL?
You should not use any window managed by a toolkit directly, unless this was some widget for exclusive OpenGL use. The reason is, that most toolkits don't create a own sub-window for each an every element and also reuse parts of their graphics resources.
Thus you should create a own sub-window for OpenGL, and maybe a further subwindow using glXCreateWindow as well.
This is an old question, I know, but the answer may help someone else.
This sounds like you're selecting a bad visual for your OpenGL window, or you're creating a new colormap that's overriding the default. If at all possible, choose a DirectColor 24-plane visual for everything in your application. DirectColor visuals use read-only color cells, but 24 planes will allow every supported color to be available to every window without having to overwrite color cells.
So I've created this program to render to a window using DirectX. It has an init() method which requires a HWND object so that it can initialize DirectX to the window, and then a render() method which is called inside of an infinite-loop, and then finally a cleanup() method to release DirectX-objects and devices. However, DirectX will render a couple of frames of a rotating cube (maybe enough for a half-rotation), and then the screen will go black. Then the cube will come back on, but it is still rotating during the black period. This continues in an on...off...on...off sort of pattern. Is DirectX maybe not rendering correctly to the window? What's wrong?
From my experience I think there is a good chance you need to explicitly implement the handling of the background erase event for your window (see this page), otherwise, the default implementation will kick in and get in your way (sometime erasing what DirectX just rendered as others suggested).
But well, as everybody mentioned already: this is only a little theory, and we would need some code to check this further :-).