Im using GLUT and i need to refresh a draw inside the idle function, my code is something like that:
void idle(){
for(int i ;i<cant;i++){
/* do some stuff*/
glutPostRedisplay();
}
}
inside the idle function proccess de data what i want to redraw in every itaration.
Someone can help me?
Do one (or few) things in idle, then postRedisplay.
Let the timer (calling idle) do the loop !
you should ensure than the computation load of idle + redisplay is largely less than the timer rate you required (or the FPS you expect).
Related
window.setFramerateLimit(60);
while(window.isOpen())
{
//manage events
}
this above while loop runs 60 times in 1 second after we set the frame rate limit, I want to know how does SFML internally manage to run the while loop in a controlled manner(i.e maintaining frame rate) by just using the "window.isOpen()" function in while loop condition. Or is there anything else working under the hood.
I am unable to understand how does setFramerateLimit works in SFML.
SFML limits the frame rate by sleeping the thread for a short interval each time you call window.display(). This can be seen in the source code:
void Window::display()
{
// Display the backbuffer on screen
if (setActive())
m_context->display();
// Limit the framerate if needed
if (m_frameTimeLimit != Time::Zero)
{
sleep(m_frameTimeLimit - m_clock.getElapsedTime());
m_clock.restart();
}
}
Without calling this function once per loop, there is no frame rate limiting.
Setting setFramerateLimit on the window will add a delay after you call window.display(). If you remove the call to this function your loop would iterate without the limit control set by SFML.
I have an application which renders a 3d object using OpenGL, allowing the user to rotate and zoom and inspect the object. Currently, this is driven directly by received mouse messages (it's a Windows MFC MDI application). When a mouse movement is received, the viewing matrix is updated, and the scene re-rendered into the back buffer, and then SwapBuffers is called. For a spinning view, I start a 20ms timer and render the scene on the timer, with small updates to the viewing matrix each frame. This is OK, but is not perfectly smooth. It sometimes pauses or skips frames, and is not linked to vsync. I would love to make it smoother and smarter with the rendering.
It's not like a game where it needs to be rendered every frame though. There are long periods where the object is not moved, and does not need to be re-rendered.
I have come across GLFW library and the glfwSwapInterval function. Is this a commonly used solution?
Should I create a separate thread for the render loop, rather than being message/timer driven?
Are there other solutions I should investigate?
Are there any good references for how to structure a suitable render loop? I'm OK with all the rendering code - just looking for a better structure around the rendering code.
So, I consider you are using GLFW for creating / operating your window.
If you don't have to update your window on each frame, suggest using glfwWaitEvents() or glfwWaitEventsTimeout(). The first one tells the system to put this process (not window) on sleep state, until any event happens (mouse press / resize event etc.). The second one is similar, but you can specify a timeout for the sleep state. The function will wait till any event happens OR till specified time runs out.
What's for the glfwSwapInterval(), this is probably not the solution you are looking for. This function sets the amount of frames that videocard has to skip (wait) when glfwSwapBuffers() is called.
If you, for example, use glfwSwapInterval(1) (assuming you have valid OpenGL context), this will sync your context to the framerate of your monitor (aka v-sync, but I'm not sure if it is valid to call it so).
If you use glfwSwapInterval(0), this will basicly unset your syncronisation with monitor, and videocard will swap buffers with glfwSwapBuffers() instanly, without waiting.
If you use glfwSwapInterval(2), this will double up the time that glfwSwapBuffers() waits after (or before?) flushing framebuffer to screen. So, if you have, for instance, 60 fps on your display, using glfwSwapInterval(2) will result in 30 fps in your program (assuming you use glfwSwapBuffers() to flush framebuffer).
The glfwSwapInterval(3) will give you 20 fps, glfwSwapInterval(4) - 15 fps and so on.
As for separate render thread, this is good if you want to divide your "thinking" and rendering processes, but it comes with its own advantages, disadvantages and difficulties. Tip: some window events can't be handled "properly" without having separate thread (See this question).
The usual render loop looks like this (as far as I've learned from learnopengl lessons):
// Setup process before...
while(!window_has_to_close) // <-- Run game loop until window is marked "has to
// close". In GLFW this is done using glfwWindowShouldClose()
// https://www.glfw.org/docs/latest/group__window.html#ga24e02fbfefbb81fc45320989f8140ab5
{
// Prepare for handling input events (e. g. callbacks in GLFW)
prepare();
// Handle events (if there are none, this is just skipped)
glfwPollEvents(); // <-- You can also use glfwWaitEvents()
// "Thinknig step" of your program
tick();
// Clear window framebuffer (better also put this in separate func)
glClearColor(0.f, 0.f, 0.f, 1.f);
glClear(GL_COLOR_BUFFER_BIT);
// Render everything
render();
// Swap buffers (you can also put this in separate function)
glfwSwapBuffers(window); // <-- Flush framebuffer to screen
}
// Exiting operations after...
See this ("Ready your engines" part) for additional info. Wish you luck!
Here is a part of SDL2 code
SDL main function
int main(int argc,char *argv[])
{
...
...
bool quit=false;
SDL_Event e;
while(!quit) ///First while (say)
{
while(SDL_PollEvent(&e)) ///Second while (say)
{
if(e.type==SDL_QUIT)
{
quit=true;
}
handleEvent(e) ;///Function for executing certain event
}
...
SDL_RenderPresent((SDL_Renderer)renderer);
}
}
My question is,what does this SDL_PollEvent() actually do ,and suppose an event occur does the execution goes out of the second while() and call the SDL_RenderPresent() or it waits for all the events to take poll and then SDL_RenderPresent() is called , i am totally confused ?
The above is a very common single thread event loop:
Basically the application is constantly inside the outer while loop. To get the smoothest user experience we try to keep this loop under 17ms (for a 60 frames a sec rate)
Every 'frame' starts by responding to all the events that are waiting in the queue (the inner while):
while(SDL_PollEvent(&e)) ///Second while (say)
{
if(e.type==SDL_QUIT)
{
quit=true;
}
handleEvent(e) ;///Function for executing certain event
}
Events are notifications from the operating system that something happened. It might be that the window is closing SDL_QUIT or that the mouse was moved.
You must respond to these events for the application to be responsive. Usually the response is to change the state of the application.
For example we might see a left-mouse is down event we might find what is "under" the mouse button and indicate that it is now selected. This is normally just finding the object and calling a function that will change its state. All that changes is the boolean value that indicates the object is now selected.
Maybe moving the mouse needs to change the point of view of the next frame so we will update the vector that stores the direction we are looking at. So we update the vector in memory.
You may have long stretches where the event queue is empty and the application does not have any events to handle. And there might be flurries of activity (for instance the user moving the mouse) where you will get lots of events to respond to.
SDL_PollEvent will not "wait" for events. If there is an event in the queue you will get the information. If there is no event it will return false.
Handling events should be done quickly (remember we have to be finished in 17ms) don't worry it is quite a lot of time on a PC.
Once you are done with all the events and out of the inner loop you are ready to move on to updating the world and rendering.
At this point you will normally do stuff like AI. Calling physics engine. For instance you might iterate over the objects and change their position based on their velocity.
The next step is to actually do the drawing.
SDL_RenderClear(renderer);
...
SDL_RenderPresent((SDL_Renderer)renderer);
The first call will clear the screen. You then go and based on the state of different objects do the rendering. For instance maybe because we changed the object state to selected we will now draw a glowing border around it.
Your final call is for SDL_RenderPresent(renderer) to present the new screen to the user
If you are using Vsync (quite common) then this final call will hide a small wait time to synch the screen update with the graphics card capabilities. This will produce a smoother graphics. Assuming a 60Hz refresh rate (60 frames per second) and assuming you are running under 16.6 ms in your frame rendering logic the app will wait the remaining time.
Now the application is ready to go back to the start of the loop and check if there are any events in SDL_PollEvent. Since the entire loop typically only takes a few milliseconds the application will always feel responsive.
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 have a main window which has both a glut UI in the top 10% of the screen, and the openGL world in the bottom 90% of the screen. Every time my cursor starts hovering over the GLUT portion, openGL rendering will freeze. It resumes only when the cursor exits the GLUT area.
This is because as long as the cursor is hovering over the GLUT area, presumably glutIdleFunc is never called because glut is not "idle", so openGL stuff is not rendered.
I already tried making a new unrelated thread that just calls the display code and/or glutPostRedisplay but I got a framerate of whopping 20 fps as opposed to the 100+ fps the normal way. I don't know exactly why. (In this test I also disabled glutIdleFunc so there is no idle func, just the separate thread calling the display)
Ways to get around this (other than "stop using glut" which I might do in the future but for now I would like a temporary solution)?
I know this is an old question, but I was having a similar issue and wanted to share how I solved it.
Basically, in your idle function, you should manually set the window to your normal window ID. Thanks to Joel Davis' HexPlanet code ( https://github.com/joeld42/hexplanet/ ) for demonstrating this:
void glut_Idle( void )
{
// According to the GLUT specification, the current window is
// undefined during an idle callback. So we need to explicitly change
// it if necessary
if ( glutGetWindow() != g_glutMainWin )
{
glutSetWindow(g_glutMainWin);
}
...
}
Create a callback for passive motion func:
void passiveMouseFunc(int,int){
glutPostRedisplay();
}
And register it using:
glutPassiveMotionFunc(passiveMouseFunc);