I get how glutdisplayfunc() makes the display loop and Iv read in some places that you should put the game mechanics in glutidle instead of the display; why can't you just put them in a while (gameisrunning) loop?
In event-driven programming, like you have in interactive OpenGL applications, the main application loop generally does three things:
- check the current event queues, and process any events (e.g., mouse movement, key presses, etc.) that have occurred since the last check
- update the application state - things like player and object positions, game physics, etc. - in preparation of the next rendering frame
- render the current frame.
GLUT does these steps implicitly in its glutMainLoop()
for you. Almost all of the GLUT callbacks you register (e.g., glutKeyboardFunc()
, glutReshapeFunc()
, etc.) take care of 1., and call functions you set up to presumably do 2.
Now, if you register an idle function with glutIdleFunc()
, it's called after all the current events are processed. Often programmers implement their idle function to merely call the routine they use for rendering their scene (i.e., the routine they pass into glutDisplayFunc()
). This approach can be problematic if rendering "takes a while" (like close to all of the time to render a frame), since you may not have time to complete rendering and then process events for the next frame. If you were to insert the while loop you mention, you'd be doing just this, which circumvents GLUT's native event processing mechanisms. The better approach to play nicely with GLUT is to implement your idle function to only call glutPostRedisplay()
, which tells GLUT to schedule a call to your display function once all the events are processed and before your idle function is called.
来源:https://stackoverflow.com/questions/15670580/whats-the-point-of-glutidlefunc-in-freeglut