GLUT is great! but -- how to break the message loop?

hello folks, glut is a really great, really simple to use CROSS platform lib. and that cross platform aspect is what i use to implement a port of gaffers tinyptc ( - a cross platform “low level graphics library for software rendering in 32 bit color”) to opengl (using ortho mode and texture blitting) for even more platforms available to tinyptc. but the interface of tinyptc allows the user to write his own “message loop”
a prog looks like this:

if (!ptc_open(“test”,WIDTH,HEIGHT))
return 1;
while (1)

thats all one needs to do all the nice demo’s or such and one is not bothered with event handling, callbacks and window-os-specific stuff. but - sadly glut needs to use callbacks and its mainloop.
but - WHY ?!?!?! - glut does not allow to set up a user mainloop - somehow like this:

// my code


so glut still could process all events and so on.
you may watch the current implementation using glut and another implementation using windows api at

(look at gl_glut.c and gl_test.c and maybe at gl.c - the win32 implementation)
i really would like to use glut instead of os dependent windows stuff. so please someone help or can convince the author of glut ??
and besides - a cross platform gui toolkit ALLOWS a user defined mainloop!!
so why not glut ?

[This message has been edited by herc (edited 05-12-2002).]
sets up your gl-window, you can do your own loop, and you can even use the glutfuncs anyways

ok, i will give it a try - but i think you can understand me - glut is installed on most systems, an sdl-port would require the user to install the sdl lib…

and besides - with sdl i would no longer need opengl :wink: – because sdl does all what tinyptc can and far more. tinyptc was developed to be much smaller, (a little easy’er) and lighter than sdl or openptc.

well… glut is normally not installed on my pc, i always have to search a glut32.dll when i download a demo…

sdl is just an sdl.dll (for windowsworlds), and so its easy as well.

with sdl you don’t need glut anymore, no, with sdl you don’t need tinyptc anymore, no. its up to you… i provided you only the solution to get rid of your problems…

yes - you are right :slight_smile:
hmm glut is not installed by default ? hmm, think i forgot that i installed glut manually decades ago :wink: besides the tinyptc and sdl stuff -

i still cannot understand why glut does not allow a user defined message loop…

There is a hack, glutMainLoopUpdate which
allows for this. sjbaker wrote it.

or search Google for glutmainloopupdate.


[This message has been edited by jmathies (edited 05-12-2002).]

thanks !
is there hope, that this hack get’s included in the official glut releases ?

Originally posted by herc:
thanks !
is there hope, that this hack get’s included in the official glut releases ?

doubtful. glut is dead. the author hasn’t
released a new version in years, and
the source is not open source. there
are a number of replacements, but none
of these have the breadth of support
glut does… yet.

Take a look at:

Cpw: (Win32)
GLFW: (X11, Win32)


It’s a shame what happened to GLUT. The author refused to incorporate needed improvements requested by developers, the splitting of the loop was the biggest issue and the most requested feature. People have been asking for this for 4 years now and have even offered the required code. Unfortunately they have been ignored. The original GLUT author also refused release it under a real open source license.

There is freeglut now, find it here:

I’m not sure how maintained this is, the latest download is fairly recent, looks like Steve Baker is the current keeper.

[This message has been edited by dorbie (edited 05-12-2002).]

With GLFW you use your own loop (“split” it however you like).

GLFW is constantly updated. It links statically with your app => no need for a separate installation, and you can include the GLFW source with your project if you want to distribute the source (it’s compact enough for that: the source for the win32 + x11 versions together is just above 200 KB, or 60 KB compressed).

[This message has been edited by marcus256 (edited 05-13-2002).]

Splitting open the loop means you write your own loop and call an event function maybe two. A key operation of splitting open the event loop is the ability to incorporate the API in other asinine libraries which insist on their event loop. Hence you need a couple of functions you can call and no loop co you can place them in a handler function (should you need to).

In GLFW you have glfwPollEvents() and glfwSwapBuffers() (which calls glfwPollEvents). All input and window events go through callback functions and/or state polling functions (e.g. glfwGetKey() and glfwGetWindowSize()).

That is truely an “open loop”. You typically do something like:

running = 1;
while( running )
    if( glfwGetKey( GLFW_KEY_ESC ) | |
        !glfwGetWindowParam( GLFW_OPENED ) )
        running = 0;

Future versions of GLFW will also have a glfwWaitEvents() function.

[This message has been edited by marcus256 (edited 05-13-2002).]

I agree this is desirable, but you are aware that you don’t have to call glut main loop now right? That’s what Steve’s hack and was all about and one of the reasons for the freeglut implementation.


If glfw added this function to the library, it wouldn’t make your version less of an open loop:

void glfwMainLoop(void)
running = 1;
while( running )
if( glfwGetKey( GLFW_KEY_ESC )| | !glfwGetWindowParam( GLFW_OPENED ) )
{ running = 0; }



[This message has been edited by dorbie (edited 05-13-2002).]

oh i see. i was offline last night, so i could not reply. i wanted to use glut mainly because its multiplatform support. now that you point out its dev is dead, it’s not so good idea to use it for the tinyptc project.
so i will have a look at glw und freeglut!
hopefully one of them evolves into a glut replacement and reaches such a broad range of platforms.

thanks to you guys anyway, greetz, herc.

p.s. hacking the glut source would not of any use, scince tinyptc is especially for users who want to code quick and not download libs, hack source and compile and get crazy with lib-deps and missing libs and so on.

Herc, you are correct, this is an almost universal viewpoint when using a library like GLUT, hence the extreme frustration with the original GLUT author ignoring the feature request.

It effectively eliminated GLUT as an option for many developers and at the time there wasn’t an alternative.

[This message has been edited by dorbie (edited 05-13-2002).]


Yes, I could add such a function, but I see no need for it right now (unless you want to make it easier to port GLUT programs to GLFW). I think most people like to have their own loop. Then you have the freedom to implement different methods for things like handling window iconification etc (e.g. pause timer and wait for window restoration).

I for one initially had some trouble understanding exactly what happened once the glutMainLoop() function was called. Personally, I think a custom loop makes a program source more readable (if it’s done right).


I doubt that GLFW will ever reach the popularity of GLUT (GLUT is almost accepted as part of OpenGL, similar to GLU). However, the goal is that GLFW should support as many platforms as possible. It’s gotten quite far, since it supports Windows 95/98/ME/NT4/2000 (and I believe XP too), plus any Unix or Unix-like station with pthreads support and X11 (it’s been tested on Irix, Linux, Digital UNIX and Solaris).

Currently GLFW is only available as a static link library, meaning that you do not need to install a shared library on your destination system. The disadvantage is of course that if you want to distribute simple tutorial-like demonstrations, the user needs to download and compile GLFW before he/she can use it, but for larger projects I see no problem with including GLFW as part of the project source.

In the future GLFW will also be available as a Windows DLL, meaning a wider range of users (Delphi, Visual Basic etc).

[This message has been edited by marcus256 (edited 05-13-2002).]

I’m not advocating it, I’m merely pointing out that freeglut is just as capable of an open loop. You still don’t seem to understand thet freeglut has the exact same open loop capability.

Like you I think an open loop makes a lot of sense, to insist (as the original author does) that GLUT retain it’s closed loop or that users should hack their own open loop in as needed is completely asinine.

Thankfully some people have reimplemented GLUT as freeglut to fix the problem.


I have nothing against freeglut. I know it has open loop support. I just happen to prefer GLFW in general. Surprised?

No, I’ve never tried it and I don’t use GLUT either although I have tried it. Surprised? :slight_smile: I preffer to grow my own, or use something with real meat on the bones.