question about glut

Member
Posts: 194
Joined: 2009.02
Post: #1
Is using glut for a c application totally safe, does it use any of the deprecated carbon stuff?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
GLUT is not deprecated, its implementation is of no relevance to you.

It's also not suitable for a shipping application. It's for quick prototyping work only.
Quote this message in a reply
Member
Posts: 194
Joined: 2009.02
Post: #3
And why isn't it suitable?
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #4
Because it tends to produce very non Mac like applications and doesn't have very powerful input handling mostly.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #5
the prefs dialog is also bad.
Quote this message in a reply
Member
Posts: 260
Joined: 2005.05
Post: #6
My experience is a different; I like GLUT a lot and can't see any problems with it. Since the full source is available (with no deprication problems), you can tune things like the prefs dialog as you please. The API is very easy to work with, and I have never found any problems with the input handling (although it is not the easiest part of the API). It is multi-window capable and has been for a long time. For other platforms, there are open source implementations like FreeGLUT.

I keep my eyes on discussions like this, trying to figure out if there is some problem that I've been missing, but so far I havn't found anything truly significant. I agree that the prefs dialog is not suitable for a shipping application, and I'd want a real about box, but we have the power to fix that. (And Apple just may accept updates.)
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #7
Though the input handling does cover most of the basics, it doesn't really help you structure your application in a any way. It's a global set of input callbacks. Most people run into problems when they try to do things like fullscreen and relative input IIRC.

While the GLUT implementation might have the source available, I'm not sure how it's easier to hack on that for each project you want it for than to make a proper native GUI application. By changing GLUT, you are already losing it's simplicity and portability which I thought were the main reasons why it existed in the first place.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #8
and the source to a Cocoa shell with better keyboard handling than GLUT, full-screen toggle, and relative mouse motion input is only about 300 lines -- a whole lot less than GLUT, and therefore a whole lot easier to modify.
Quote this message in a reply
Member
Posts: 260
Joined: 2005.05
Post: #9
OneSadCookie Wrote:and the source to a Cocoa shell with better keyboard handling than GLUT, full-screen toggle, and relative mouse motion input is only about 300 lines -- a whole lot less than GLUT, and therefore a whole lot easier to modify.
But much, much harder to port to other platforms.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #10
300 lines for a well-behaved Cocoa windowing base is a bit short, although it is doable I suppose, and would probably offer as much, if not better OS integration than GLUT.

OTOH, porting a windowing base to other platforms isn't trivial. If it were then we wouldn't have SDL.

For Mac, Cocoa is the best approach to the windowing layer. For the most full-featured cross platform, and at least somewhat easy, SDL is the way to go -- although it is still restrictive.

The easiest cross-platform for sure is GLUT. The problem is that ease of use really doesn't cover anywhere near the number of bases something like SDL does, nor does it have anywhere near the Mac flexibility of Cocoa.

I think GLUT is "okay", even for commercial products, up to a very short point, but there's no way I'd recommend it. I've played many games on the Mac and other platforms which use GLUT and I had fun, and it didn't screw up my system, and those were the two most important things. But still, GLUT is very spartan. I can't in good conscience agree that it can be "recommended" for any released app on any platform (except Windows, where GLUT looks like a beauty queen Rasp). You really need to make a strong effort to provide users with a good native interface if possible, and that's not what GLUT is intended for.
Quote this message in a reply
Member
Posts: 260
Joined: 2005.05
Post: #11
Skorche Wrote:By changing GLUT, you are already losing it's simplicity and portability which I thought were the main reasons why it existed in the first place.
That depends entirely on how you modify it. If the API remains 99% the same, but you improve the general look, and revise the settings dialog... Because the API is what really matters, and the API is very good.

The whole problem is quite a concern to me. I wasted enough time on GL in the past, which was clumsy and bug-ridden, and totally non-portable. Locking my code into Cocoa makes no sense to me. GLUT is nice, almost all I want. SDL covers too much, never quite found it to be right for me, plus that it is really only for games. GLFW is also mostly a game tool, with a level of control that might feel nice except that it feels a bit old-style to me (while GLUT is, frankly, much more modern in its approach).

There is no such thing as an optimal solution for all purposes, but I can't quite see the best one for my needs. The closest I get is some kind of "GLUT Plus". As always, I guess there is only one way out that will give me what I want: Make my own solution.
Quote this message in a reply
Post Reply