i just started off using OpenGL and it seems it is not easy to understand the working of the glutMainLoop() what really happens there? Does it stay there doing nothing till any of the function calls responds?
It calls your display callback over and over, calling idle between so that it can maintain a specific framerate if possible, and others if necessary (such as if you resize the window or trigger an input event).
Essentially, within this function is the main program loop, where GLUT does most of the work for you and allows you to simply set up the specific program logic in these callbacks. It's been a while since I've worked with GLUT, and it is certainly confusing at first.
In your display callback should obviously be your main logic to draw whatever it is that should be going on. In the idle callback should be some very lightweight operations to determine what the change in state should be from the last time display was called to the next time. For example, if you're animating something, this would be where you change its position or orientation.
It is exactly as StrixVaria has stated.
glutMainLoop enters the GLUT event processing loop. This routine should be called at most once in a GLUT program. Once called, this routine will never return. It will call as necessary any callbacks that have been registered.
Taken from here
Using opengl and glut together means that you would be writing a 'glut' program that uses opengl commands in the callback functions. main contains glut functions. many glut functions need a callback function to be registered. Those callback functions usually contain opengl commands.
Coming to your question, now when it is clear that you are mainly writing a glut program, it should also be taken that glutMainLoop function call actually executes the callback functions as and when required, which in return executes the opengl commands.
Well glutMainLoop is the main function the keeps calling and calling the displaying functions and which also keeps your window actually opened. You''ll find out that opengl is not that scary.
Related
So far, I've only copy/pasted the example that Microsoft has here (but I removed #include ).
I'm trying to figure out how OnPaint is continually called (as to have moving objects), but it doesn't seem to be called more than once.
How do I use the standard Windows C++ graphics library (i.e. GDI+, or another standard Windows API) to create a moving object? Must I call OnPaint myself? Or is there an easy fix to make it continually be called? Or is it just not possible?
The OnPaint() method will only run when Windows thinks that your window needs to be repainted. Which, typically, happens just once when your window is first created. Or when you minimize and restore the window.
To force it to run more than once and animate something, you'll have to tell it that a repaint is required. Best way to do so is by using a timer, it will give you an animation clock. Set the interval to a number that's a bit less than a multiple of 15.625 millseconds. 45 msec is a decent value, it gets you 21 updates per second. Assuming that you can paint fast enough. Call InvalidateRect() in the WM_TIMER message handler. Or Invalidate() if you use Winforms.
I have a program which updates it the program output then the state of the program changes. This happens when a ticker of the time (not an openGL timer, one implemented in threads) happens, and when keyboard input is registered from glut (using glutKeyboardFunc callback).
Both of these events update the programs state and call glutPostRedisplay; the problem is only the when the keyboard is pressed does it actually do anything. When the timer ticks the display function is ignored, but when the keyboard is pressed the display function is called.
Does glut ignore other threads? And if so is there a way to get it to register them.
You cannot call glutPostRedisplay or most other GLUT functions from a thread other than the one GLUT was initialized in. GLUT is not thread-safe.
I would like to control the main loop in a glut program, I would like to better understand what is the order of execution of the following callbacks:
glutDisplayFunc(drawGLScene);
glutIdleFunc(idle);
glutTimerFunc(TIMER_MS, update, 0);
It's difficult for me to understand how glut queues this calls in a program.
As soon as you want fine control of your event loop, it's time to abandon GLUT. Use SDL, GLFW or do it from scratch. Understanding the inner workings of GLUT will not help you to gain fine control.
You can't. If you want to control the main loop you're going to have to use something like GLFW. Freeglut, a more modern extension of glut might let you do this. The way GLUT works is you specify some callbacks, start the main loop, and then it will call the callbacks whenever appropriate.
It probably calls the timer callback at the beginning of the frame so that you can update your time-since-last-frame value, it probably calls the display callback whenever it needs to render a frame, and it probably calls the idle callback whenever it has to wait before rendering the next frame (maybe in the case that your framerate is limited to exactly 60 fps so if you are rendering frames in less than .017 seconds then it will probably call the idle callback until it is ready to push a frame to the screen).
I'm writing a game for school in OpenGL. Since there will be several more similar assignments I want to make a small framework for doing common things in OpenGL. I have made a few simple games before and I usually break it down into an IO class to handle input and drawing to the screen, Game class for the main game loop/logic, and classes for whatever objects there are in the game.
Before I was using SDL, so my question is, is this the right way of going about this in OpenGL? I've already ran into some trouble. I want my IO class to handle initializing the window, drawing the scene, and mouse clicks. So the constructor looked like this:
IO::IO()
{
currWindowSize[0] = DEF_WIDTH;
currWindowSize[1] = DEF_HEIGHT;
glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGBA );
glutInitWindowPosition( INIT_WINDOW_POSITION[0], INIT_WINDOW_POSITION[1] );
glutInitWindowSize( currWindowSize[0], currWindowSize[1] );
glutCreateWindow( "TEST" );
setUp();
glutDisplayFunc(drawScene);
glutMainLoop();
}
However, drawScene is a class method. Is there a way to pass a class method to glutDisplayFunc() without making it static?
Unfortunately the glutDisplayFunc() doesn't take a void* pointer so you could've fake an object context. You will have to make a static function that can call into the correct IO instance using a static variable.
I see some slight trouble with your pattern also, though. As far as I know, glutMainLoop() never returns until you terminate the GLUT context, therefore you have a constructor that practically never returns, so your program flow is unreasonable. You should move that call into a separate run() method in your class.
(Personally I would use GLFW, which avoids the entire callback mess with GLUT, although you have to write your mainloop.)
Two points,
First, glutMainLoop never returns, and starts dispatching messages. Because you called it from your constructor your class is potentially not properly constructed yet. Additionally glut does support more than one window, and glutModalLoop only needs to be called once.
Second, as you have noted, the method passed to glutDisplayFunc must be static. You will need a static array associating glut window id's with IO pointers. When glutCreateWindow is called by an IO instance, store the returned id and IO instance in the array. Whenever the static drawScene is called you would call glutGetWindow to get the id of the current window, and look up the associated IO pointer and call the non static drawScene implementation.
Before I was using SDL, so my question
is, is this the right way of going
about this in OpenGL?
I'd rather bypass GLUT completely (if you want to learn the inner guts of OpenGL and your OS windowing system interface). Plus GLUT is not supported on the iPhone (if you want to target this platform in the future).
So the idea would be to use WGL on Windows, GLX on Linux and CGL on OS X.
I've made a project with Qt and OpenGL.
In Qt paintGL() was repeatedly call I beleive, so I was able to change values outside of that function and call update() so that it would paint a new image.
I also believe that it called initializeGL() as soon as you start up the program.
Now my question is:
I want that same functionality in a different program. I do not need to draw any images, etc. I just was wondering if there was a way to make a function like paintGL() that keeps being called so the application never closes. I tried just using a while(true) loop that kept my program running, but the GUI was inactive because of the while loop.
Any tips, other than threading preferably.
Thanks.
The exact mechanism will depend on which GUI toolkit you are using. In general, your app needs to service the run loop constantly for events to be dispatched. That is why your app was unresponsive when you had it running in a while loop.
If you need something repainted constantly, the easiest way is to create a timer when your window is created, and then in the timer even handler or callback, you invalidate your window which forces a repaint. Your paint handler can then be called at the frequency of your timer, such as 25 times per second.