PDA

View Full Version : A suggestion for GLUT- allow N buttons



147-2
11-08-2002, 10:26 AM
I noticed that the last release of GLUT is shortsightedly limited to 3 mouse buttons and 4 joystick buttons. Why not allow N buttons on a mouse in the API, so that when the appropriate drivers are created, the functionality may be implemented without requiring an API change.

I suggested this in the "suggestions for upcoming OpenGL features" but was told to suggest this here.

Rob Stoddard

Rob Fletcher
11-11-2002, 07:56 AM
But it won't do any good as GLUT is not being updated or maintained.

I have tried to talk with NateR and/or MarkK about releasing some updated sources and builds, to no avail. Humph!

In the meantime, the way round it as I see it is for those who make changes is to send out the full source, with their changes as patch files, and then let users patch their source codes and re-build as necessary!

Sigh .......

Or, users go for a different/newer package, and I am sure there are a few who pop in here who would recommend something! ;-)

Rob.

147-2
11-12-2002, 12:31 PM
I modified the original source, but only for the mousewheel. Its not hard, thats for sure. Since GLUT is not being maintained/updated, maybe it would be possible to obtain the right (or rights) to maintain the source. I will look into it, but I really don't feel like maintaining GLUT all by myself.

Rob Fletcher
11-13-2002, 07:58 AM
I added in the glutCheckLoop() to split off the glutMainLoop() (modified version of the original hack by Steve Baker)

and also WMCloseFunc()

which allows you to register a callback (per window) to trap the close window message (or client message in X-Windows), to stop the application simply shutting down when a user closes the window!

Did you update the sources for both Windows and Unix?

Rob.

147-2
11-13-2002, 01:27 PM
actually I havent because the support for mousewheel is sooo shaky, individual installs will have different button numbers for the mousewheel, usually 4 and 5 for up and down. When I coded mine, I decided I'd save on "buttonspace" by making the wheel one button, and use the up-transition as up, and the down transition as down. Mind you, this is just my little hack and I dont mind having something that runs on windows only at the moment. Mebbe we should all sit down and hum-haw about what should go where, and how we are going to support what in this ever changing world of mice.

But for now, do we have authorization to modify and release GLUT changes?

jmathies
11-13-2002, 07:49 PM
Originally posted by 147-2:
But for now, do we have authorization to modify and release GLUT changes?[/B]

Nope.

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

Regards,
Jim

ldglite
11-14-2002, 05:24 AM
Maybe so, but what do you propose as a replacement? GLUT is small, fairly easy to use and runs on just about anything. Plus there about a zillion example programs out there that use it.

Rob Fletcher
11-14-2002, 08:00 AM
Jim ... you are right. Can't release new stuff etc etc, and yes it's unsupported, a bit buggy, and I guess for a lot of people a bit of a pain to use in a pure C++ environment. [But let's not forget the Fortran people out there who use GLUT!]

The "replacement" cross-platform libs out there all do much the same as GLUT in various ways, and with varying levels of success re full cross platform, C++ conformance, and so on.

Ease of use is also another issue as well as lots of example OGL code out there based on it in order to run (heck even nVidia demos use it!).

The problem is that if GLUT had been supported, and used as much as it is now (back in them thar olde worlde days), it might have developed into a better package and even made a transmogrification into GLUT++ as well!

I have no simple answer.

Rob.

147-2
11-18-2002, 11:35 AM
Well, I would say it is probably easier to fix what's broken on GLUT than it is to write a whole new lib. I for one am glad GLUT is not a C++ lib, even though I have programmed in C++ for 10 years or so, I shudder at the thought of using a C++ lib. There are a lot of ppl out there that try to create libraries for C++ and end up creating something thats unintuitive, and a real pain to use. Id rather stick to a C library. At least there I know what a function requires, and I can differentiate library functions from my program's functions, since my program is in C++, and the funcs are in structs/classes, and the lib's funcs are global.

Anyways, I would like to see GLUT grow into something useful, and having it be supported by one or two individuals is not going to accomplish that. There are a lot of programs and examples that use GLUT, plenty of authors who have written books on GLUT, etc. Why throw away all that good work because of a few problems?

How bout we see if we can do this. Im interested in putting in my two cents on such a project.

jmathies
11-18-2002, 06:15 PM
Originally posted by 147-2:
Anyways, I would like to see GLUT grow into something useful, and having it be supported by one or two individuals is not going to accomplish that. There are a lot of programs and examples that use GLUT, plenty of authors who have written books on GLUT, etc. Why throw away all that good work because of a few problems?

How bout we see if we can do this. I'm interested in putting in my two cents on such a project.

There are more than a few problems with GLUT. There are licensing issues, code issues, support issues, etc.. For example:

1) the code base is an antique, it does not support (nor could it) the latest hardware out there.

2) the code base is generally a hack. Not maintainable, hard to debug, impossible to expand upon, impossible to interface.

3) the author has abandoned the project, hence there are no updates.

4) the author refuses to open source it, so no other authors can fix the many problems it has.

5) the source is, at best, unreliable on 90% of the world's desktops and has contributed to the perception that OpenGL is unstable.

Currently, there are not good cross platform replacements. If you really want to put effort into this type of a project, try working on some of the modern replacements to improve their functionality, and support. That, would be a better solution. IMHO.

Regards,
Jim

jmathies
11-18-2002, 06:16 PM
Originally posted by ldglite:
Maybe so, but what do you propose as a replacement? GLUT is small, fairly easy to use and runs on just about anything. Plus there about a zillion example programs out there that use it.
http://www.mathies.com/glfaq/

Pick one.

Regards,
Jim

ldglite
11-19-2002, 05:55 AM
>http://www.mathies.com/glfaq/
>Pick one.


If you look at the list of windowing application frameworks, there really aren't all that many choices. Only SDL covers as many platforms as GLUT, so I guess that's the way to go. Too bad nobody ever put together a GLUT emulator on SDL (SLUT?). That might make the transition a bit less painful. I wonder if some of the freeglut code could be pasted onto an SDL backend...

marcus256
11-19-2002, 12:01 PM
>Only SDL covers as many platforms as GLUT,
>so I guess that's the way to go.

Unfortunately SDL is not quite as portable as one would think. Yes, it says: Windows, Linux, QNX, MacOS etc etc. But, have you ever noticed that the SDL apps/demos/games at the SDL page have "compability ratings"? In fact, if you probe the SDL source, you'll find lots of strange things, like unimplemented functions on some platforms - beceause it "can't be done" (or is very difficult to do/emulate). Which, sadly, is not mentioned in the docs (I even hear people say "use the SDL source for a manual").

Don't get me wrong. SDL is a great toolkit, but it (currently) has some flaws (especially regarding portability) that you should be aware of. I personally think that an API redesign is necessary to get SDL robust enough for the portability that it currently claims to have.

Anyway, all toolkits have pros and cons. None of them is really "there" yet (lack of maintinance, lack of portability, lack of language/compiler support, lack of robustness, lack of documentation, lack of features, etc).

It is not very likely that any single toolkit will become the GLUT replacement in the future. So my advice is to check out all the toolkits in the mentioned FAQ, and pick the one that fits your needs the best.

Hrm, was I too verbose again? http://www.opengl.org/discussion_boards/ubb/frown.gif

marcus256
11-19-2002, 12:21 PM
Originally posted by ldglite:
GLUT is small

Compared to what? The library source is > 1.4 MB (win32+x11), and the Windows DLL is > 150 KB.

GLFW (being a minimalist OpenGL toolkit): source 325 KB (win32+x11), Windows DLL 28 KB

Of course, SDL is a bit bigger (almost 4 MB for the soruce and > 200 KB for the DLL), but then again, it's not a pure OpenGL toolkit.

ldglite
11-19-2002, 01:11 PM
Glut is small compared to MFC, QT, GTK, VB, OpenGL/Mesa, and for that
matter my executable (~500K stripped). These days, a 200K static
library linked the the application is not really a problem for me.

GLFW might be nice and small, but I require MAC support so it's useless
for me, no matter how small it is.

By the way, if none of the listed windowing toolkits will ever be able to
replace GLUT, why bother. Why not work on freeglut? What's so bad about
the GLUT API that everyone feels the need to come up with their own. If
the GLUT code turns your stomach, fine, replace it. But is the API all
that bad? I don't think so. In fact, it seems pretty darn similar to the
APIs in all these newer (but somewhat lacking) toolkits. All of them
could have been done using the GLUT API with a few modern tweaks that
mirror the functionality of the GLUT patches listed on the toolkit FAQ.

marcus256
11-20-2002, 02:48 AM
GLFW might be nice and small, but I require MAC support so it's useless
for me, no matter how small it is.

I would also like to see a Mac port of GLFW, but until someone gives me a Mac or decides to do the port himself, it won't happen (sadly). I think a MacOS X port shuldn't be hard to do (a guy did a rough draft with the basics and could compile & run most GLFW demos). A nice thing for instance is that MacOS X has pthread, so you can basically rip the X11/Unix code for the threading part of GLFW http://www.opengl.org/discussion_boards/ubb/smile.gif


By the way, if none of the listed windowing toolkits will ever be able to
replace GLUT, why bother.

With "replace", I mean all aspects of GLUT, including legacy code compability etc (which is impossible without doing a GLUT API implementation - just as freeglut does). Most toolkits are able to replace (and surpass) GLUT for certain/most tasks, but that requires that the programmers start from scratch, and do not rely on GLUT (for instance, you can't use GLUI with any toolkit other than GLUT).


Why not work on freeglut?

Honestly, if I knew about freeglut before I started coding GLFW, GLFW would probably not exist today. On the other hand, I know many people who are very happy that GLFW does exist.


What's so bad about the GLUT API that everyone feels the need to come up with their own. If the GLUT code turns your stomach, fine, replace it. But is the API all that bad? I don't think so. In fact, it seems pretty darn similar to the APIs in all these newer (but somewhat lacking) toolkits. All of them could have been done using the GLUT API with a few modern tweaks that mirror the functionality of the GLUT patches listed on the toolkit FAQ.

I think that in order to bring GLUT up to speed, you would have to either break compability or introduce much redundant functionality (have both old and new versions of the same basic functionality), which, in the end, is not much different from a completely new API.

The toolkits may look the same, but it's the fine points that make a difference. I am thinking about things like:

- Keyboard (one or two degrees of finer key selectivity wouldn't hurt, and for instance, how do you know if the key "4" is pressed, regardless of modifiers?)
- Joystick (1 stick, 3 axes, and no Linux support isn't really cutting it)
- Timer (10-50 ms resolution, not enough for most programs, especially games)

You can't bring these modifications to GLUT easily without messing up or bloating the API. Well, prove me wrong, but I don't think GLUT would be much easier to use, meaning that an alternative, clean cut, toolkit may be worth considering.

ldglite
11-20-2002, 05:29 AM
I think you're taking the wrong approach. Think about starting from a
smaller, cleaner, lower level cross platform toolkit (like say glfw)
that already has those hooks. 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. If you
do it right, it should be easy to add a GLUT-like function call for
advanced keyboard access and a high resolution timer. And there's no
reason why you couldn't add other input extensions to the GLUT API for
your super joystick, or power glove, or whatever.

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. Please take a look at the freeglut source and
at least consider what it would take to layer it on top of something
smaller and more modern before abandoning all the good things that
have been done with GLUT.

147-2
11-20-2002, 03:40 PM
Well, it simply comes to this. There are implementations of GLUT out there, but what needs to be renewed is the specification. There are plenty of books and tutorials out there for GLUT, if it isn't supported then we lose all of that good work.

What needs updating is the GLUT API, not the code. Well, the code does need updating, but if we modernize the API, and then the code to follow suit, then we have a workable standard. To throw away GLUT because it isnt modern or has a few problems is to throw away a lot of ppl's work, including books, demo programs, some of the most used tutorials, etc.

marcus256
11-20-2002, 10:08 PM
Originally posted by 147-2:
what needs to be renewed is the specification.

Exactly my point. You need to take GLUT in new directions and change the API. What I am saying is not that you should scrap GLUT, but it lacks some things in its design. Alternate toolkits are there to fill in those gaps, not by saying "GLUT sucks", but "GLUT is good for [this], but this toolkit is better suited for [that]".

I see no point in making GLUT cover the entire range of features offered by other toolkits, such as FLTK, GLFW, CPW etc. It would make GLUT HUUUUGE and incomprehensive (to say the least).

Rob Fletcher
11-21-2002, 12:47 AM
Hi,

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!


So, the question becomes ...

Which, of the packages out there could host a GLUT emulation layer?

If there is one, there must be a number of people who could help write the layer. I would!

Of course, the underlying non-GLUT package API would still be available for use so the extra added support etc etc could be used either as full standalone "package-A", or in tandem with the "GLUT" layer calls.

A tall order, but surely not impossible. Most of the packages have to provide the basic stuff anyway, and let's face it, GLUT really is only providing the basic stuff, which is why people are "muttering".

Any takers, packages and/or helpers?

Rob

marcus256
11-21-2002, 02:54 AM
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.

Rob Fletcher
11-21-2002, 08:26 AM
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?

Rob.

jmathies
11-21-2002, 09:12 AM
Originally posted by Rob Fletcher:
Hi,

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.

Regards,
Jim

jmathies
11-21-2002, 09:14 AM
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. http://www.opengl.org/discussion_boards/ubb/smile.gif



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.

Regards,
Jim

marcus256
11-22-2002, 10:35 AM
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...).

marcus256
11-22-2002, 10:38 AM
Rob,


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

...yes (doing it now)

valmian
11-25-2002, 11:47 AM
Originally posted by jmathies:
Nope.

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

Regards,
Jim



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

147-2
11-25-2002, 12:43 PM
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.

Rob Fletcher
11-26-2002, 12:37 AM
Hi,

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!

bloc
12-10-2002, 03:30 AM
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?

b.

Rob Fletcher
12-11-2002, 12:50 AM
Hi

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 ...

Rob.

bloc
12-13-2002, 03:46 PM
I stumbled across this link. http://freeglut.sourceforge.net/

This will be fantastic if it turns out semi workable. Wahoo http://www.opengl.org/discussion_boards/ubb/wink.gif

147-2
12-16-2002, 11:10 AM
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 :P 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.

http://www.opengl.org/discussion_boards/ubb/smile.gif