Sign in to follow this  
walesca

Close window glut automatically and continue execution

Recommended Posts

 
I'm using the freeglut library to create a window and interact with a game. In main, I create this window: (I use linux)
 
int main(int argc,char **argv) {
 
    glutInit(&argc,argv);
    glutInitDisplayMode(GLUT_SINGLE | GLUT_RGBA);
    glutInitWindowSize(500,500);
    glutInitWindowPosition(100,100);
 
    win = glutCreateWindow("JOGO");
    createMenu();
 
    glClearColor(0.0,0.0,0.0,0.0);
    glutDisplayFunc(disp);
 
    glutSetOption(GLUT_ACTION_ON_WINDOW_CLOSE,
    GLUT_ACTION_CONTINUE_EXECUTION);
 
    glutMainLoop();
 
The problem is: what comes after glutMainLoop (); only runs when the window is closed by the user. I would like a function that automatically closes the window and continues execution.

Share this post


Link to post
Share on other sites

IIRC glut was just created to allow easier creation of simple OpenGL demos having a single window for the lifetime of the program.
You are probably better off using a more modern library like GLFW, which gives you more options.

Share this post


Link to post
Share on other sites

IIRC glut was just created to allow easier creation of simple OpenGL demos having a single window for the lifetime of the program.
You are probably better off using a more modern library like GLFW, which gives you more options.

 

YEP. Glut/FreeGlut aren't even maintained anymore.

 

Go GLFW. And, since you were using Glut, it's very likely you were using GLEW, too. Use Glad (https://github.com/Dav1dde/glad or http://glad.dav1d.de/), instead. GLEW is being dropped little by little.

Share this post


Link to post
Share on other sites

Use glutMainLoopEvent instead. Put this in your own while loop and you get to control the lifespan of your program more directly. I.e when you leave your loop, the application can end.

Make sure to include <GL/freeglut.h> instead of <GL/glut.h> because this function is only available in the extended FreeGLUT feature set.

The last commit to FreeGLUT was in 2016-02-21 so is... stable lol. Hoever work has been done on it since then to port it to i.e Emscripten / WebGL. I like that the API is simple and provides a very diciplined set of features. On platforms providing their own random APIs such as Android, Marmalade, iOS etc, I always make a Glut-like wrapper so the core of my code is very portable. So I actually recommend keeping with Glut.

Also, for DirectX, check out DXUT (A clone of Glut for DirectX, used to be part of the DirectX SDK, now a separate project).

For more information on FreeGLUT, check out the API docs. http://freeglut.sourceforge.net/docs/api.php

Edited by Karsten_

Share this post


Link to post
Share on other sites


Use glutMainLoopEvent instead. Put this in your own while loop and you get to control the lifespan of your program more directly. I.e when you leave your loop, the application can end.

The main loop implementation in Glut/FreeGlut is awful. The way it gather events, the way it work with timers.

The last commit to FreeGLUT was in 2016-02-21 so is... stable lol.

Dude, this was EONS ago. GLFW, SFML, SDL2 all have commits that date days ago.

Share this post


Link to post
Share on other sites

Dude, this was EONS ago. GLFW, SFML, SDL2 all have commits that date days ago.


Yeah I know but it is simple. Sometimes simple is nice because if all else fails, I can fall back to it and maintain it myself if needed for a specific requirement / platform.

Also, being simple means it is first in line for a port. I.e to Emscripten it was pretty much released with the compiler. Whereas GLFW and SDL2 came almost a year late. SFML is still not supported either.

As for the main loop in Glut. Many platforms don't let you control the main loop directly (i.e again, Emscripten, Android etc...) or they become "unresponsive". Glut's janky C callback system actually works quite nice with this restriction.
For timers, I just don't use them. I generate a time delta and a frame limiter just like I do when using GLFW.

To be fair, these libraries are all pretty much the same. They just need to open a darn window without manually coding horrid WinAPI or X11/xcb C code ;)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this