A suggestion for GLUT- allow N buttons

Hello Rob,

The thought has tickled my mind several times, but until I get support for multiple windows into GLFW I don’t think there is much use to do the GLUT emulation layer. Another key point is the support for callbacks for redraw events and such, plus the long overdue glfwWaitEvents() function.

So basically, with release 3.0 of GLFW (which will not happen until “all of the above” has been implemented), I suppose it is ready to host a more or less complete GLUT emulation layer. Perhaps not 100% compliant with the GLUT spec, but it should compile and run most legacy apps, I believe (which is what should be the goal, imho).

Alos, since I like to keep GLFW minimal, I think the best way is to make the GLUT emulation layer as a separate lib, or at least as a compile time option.

Hi Marcus,

I expected you to reply!!!

Yes, a separate lib …

Perhaps we should start new thread here, as
we are really OT.

So, how long before release 3.0 then?

Perhaps even a basic start could be made though to test the theory!

Should we have a go?


Originally posted by Rob Fletcher:

Well, as I can see from reading this, th emain arg for using GLUT is to support the huge range of “legacy” apps, books, tutorials etc …

So, the real way to combat this is to provide a GLUT emulation layer to sit on top of a.n.other “better, better engineered, more robust, more extensible, free, etcetc” support package!


Cpw can support this very easily, it was designed as a GLUT replacement, and emulates all of the GLUT calls in one way ro another. I’ve ported GLUT demos to it by simply doing a few search and replaces in the demo.

As for an emulation layer, that’s on my todo list but haven’t gotten around to it. I’ve sort of been waiting to see if some Linux hacker out there would write a linux adpater for it first. So far, no takers. I did get a PASCAL port the other day though, which was really cool to see.


Originally posted by ldglite: …Then see what it would take to provide
a GLUT API layer on top of it so people could still use GLUI and GLOW
and all the other code that’s already layered on top of GLUT.

This is entirely possible, with the new toolkits. The point of open sourcing
these libraries is to get people like you to do just that.

Don’t forget how many users Microsoft has captured with their embrace
and extend policy. OpenGL needs to leverage the success of GLUT if
it’s going to survive.

I don’t feel this is the case at all. IMHO, GLUT’s instability is one of the primary
reasons why OpenGL has lost favor on Win32. Which, for me, was the primary
motivation behind my development of Cpw. Microsoft’s embrace and extend
policy has nothing to do with this. They developed a competing API
which is “modern”, and they support it with modern toolkits. OpenGL
on the other hand has recently been hurt more through the slow as snails ARB
and by antiquated, buggy, license limiting toolkit libraires like GLUT. Which is
not to say GLUT has always had this effect. It was a very useful toolkit back
in the day. But it has antiquated, and the Win32 port is a hack. Microsoft,
for it’s part, has implemeted the fastest OpenGL software rendering library in
existance, and has continued to support OpenGL even though very few
people are using it on their platforms.

And I don’t believe that GLUT just requires a few “tweaks” to fix it. Quite the contrary,
it requires a complete re-write, and new functionality which brings it up to snuff
with modern day os capabilities. But since GLUT is debilitated in so many ways this
will never happen, and since Freeglut has taken the stance of “emulating” GLUT’s
functionality completely, it too suffers from the same shortfalls.

I wrote Cpw because I needed a number of features GLUT did not support. For example:

  1. window specific events
  2. embedded environments support
  3. TrueType font support
  4. better timing
  5. better joystick support
  6. drag and drop support
  7. more control

…the list goes on.


Hello Jim,

Yes, I too think that Cpw is better suited to emulate GLUT than GLFW is. GLFW is getting closer day by day, but it’s based on a slightly different philosophy. For instance, a fullscreen window is always a fullscreen window, not something you “switch to” as with glutFullScreen(). Also, GLFW will probably never have things like font rendering or popup menus.

By the way - if you wish to do a Linux port yourself (it’s not that hard, really), you can always install Linux (I use Mandrake - easy to use, very easy to install to coexist with Windows, and supported by nVidia drivers), and check the GLFW source for starters (not exlusively fun reading, but…).


Perhaps we should start new thread here, as we are really OT.

…yes (doing it now)

Originally posted by jmathies:
[b] Nope.

Besides, it’s time GLUT died. The library is a pile, IMHO. It’s antiquated, unsupported, and buggy.



I like glut, it has its problems but who doesn’t?

IMHO GLUT is well known, and there are freely available/modifiable packages out there that do what GLUT does (freeGLUT for example). The fact that the original GLUT lib is a “piece of work” is not in question, what I want to know is where does one go to get a revision of the API, so that ppl writing things like FreeGLUT and other such libraries will not diverge from the standard. The question has so little to do with the library as is, that most of the ppl posting obviously haven’t read before replying. In conversations, you usually have a “three minute rule” or something, I think it should apply here. 26 posts in response, and apparently only 4 were made by ppl who actually read the forum!

All I was saying was that the GLUT API standard should be opened up to allow for more buttons, the work involved is minimal in that regard. A change in the standard which defines what happens when a button is pressed… thats what I’m aiming for.


I understand your frustration about the GLUT API. What you are asking for is not going to be possible.

Permission will not be given to change the API of GLUT and distribute new versions. Believe me I have tried!

The only way forward for those who really MUST stick with GLUT is to code up their changes, put them in a patch file and make their patch available to those who can rebuild GLUT from source.

I suggest that you can then distribute a NEW version in a sense that the distribution is the ORIGINAL code which is then patched to upgrade to a new version. (Hence the reason I make MY changes available as source).

The only way to get away from this “silliness” is to move people and programs etc to a new less restrictive support package.

For those who still really MUST have GLUT, then the idea of someone writing an emulation layer is not so silly!

I agree with everyone here, that GLUT should be allowed to evolve. Either by the original coders, or by open sourcing glut so other people can take up the cause.

I think people who learn opengl refer to glut because it’s used in the red and blue books. It would suck if glut becomes irrelevant and the books are reprinted with win32 api. It’s not inconceivable…

I’m still not exactly sure why the author is stopping development? Some NDA’s with os makers? It’s certainly not for $$ as it’s already free. Ego? When juxtapose to opengl, this little api is insignificant.

I’ll just use win32 I guess. Would have been nice to support glut as that’s what I learned on.

Anyone wanna start some kind of movement to rejuvenant glut?



Have emailed Mark K a number of times. No replies…

I wonder if the problem is at SGI where MK worked when he developed the code originally.

Are there pieces of code snaffled from other ongoing SGI projects? etc…

Until MK releases (or is able to release) the code into the PD, then there is really no chance to do anything further.

The only alternative, if the current printed sources are to be useful, is to provide GLUT emulation (for at least those functions used in e.g. Red Book), as a layer on top on a.n.other package.

If a “restricted GLUT API” is done, I would suspect that most of the other packages out there would be able to support the emulation.

Providing 100% emulation for the whole GLUT API is of course harder, and more of the alternative API’s will fall by the wayside.

So, perhaps the first shot HAS to be to provide the emulation for the most used functions as per the majority of tutorial materials out there.

Anyone care to make the list of GLUT calls used e.g. in latest Red Book and some of the most used net-tutorial sites?

Post it into a new thread and then maybe those of us who are thinking about actually doing the work will have a reference.

We can make THIS a reality I’m sure …


I stumbled across this link. http://freeglut.sourceforge.net/

This will be fantastic if it turns out semi workable. Wahoo

Yeah, but the problem with that is that if you change the specification without a standard, then glut implementations will diverge. Plus, I recall that there are some specific rights that have to be maintained WRT the GLUT API. The problem with this is that we wish to change the API, and I doubt that may happen without the permission of the authors, who seem quite opposed to allowing GLUT to grow/change. So, I was thinking that Id be the last to say this, but GLUT (in my mind) is dead. I switched to GLFW, which is a very well documented approach to OpenGL system independance. There is one feature missing, fonts, but those may be obtained thru the GLF library. My only remaining contention with GLFW was its lack of support for OSX. I suggested that I may help with an OSX port once my finals were completed, but methinks that the port will be complete before my finals are :stuck_out_tongue: I was quite amazed by the speed at which the people on this forum have attacked the port-problem that I suggested. I was thinking that Id end up doing most of it myself, but I was dead wrong. I really like that.