macOS So GLUT, SDL or Carbon?

[Cromulent]

So I have been trying to teach myself OpenGL for awhile and have been getting better at it. But I'm constantly reminded of the limitations of GLUT and the rather annoying API of SDL. I was thinking of using Carbon in the mean time as I am sure it offers more power as it is one of the native APIs for Mac OS X.

So the question is for basic event and window handling along with future expanision in ability which is the best choice? I'm not looking for cross platform compatibility (if I was I'd choose SDL) nor am I looking for suggestions to use Cocoa (I'm learning C and am keen not to confuse myself with other languages while I do so).

 

[AlmostThere]

If you are learning C and OpenGL, then stick with GLUT. You are already trying to learn a language, an API and a certain amount of geometry, so the less you add to that, the better.

Without specific examples of the limitations, it is hard to comment, but see if freeglut ( http://freeglut.sourceforge.net/ ) addresses them. If you really need a few widgets to help you out, have a look at GLUI ( http://glui.sourceforge.net/ ).

 

[Animalk]

My experience with glut is bitter-sweet. While it has several useful, but basic, drawing functions of various geometrical shapes and some transformations, GLUT is not texture friendly. I found myself redoing many of my models with my own homebrew draw functions that mimic the GLUT functions but apply the texture points according to what i wanted. Applying textures to GLUT objects is like playing the lottery. Who knows what you'll get.

 

[Krevnik]

My experience with glut is bitter-sweet. While it has several useful, but basic, drawing functions of various geometrical shapes and some transformations, GLUT is not texture friendly. I found myself redoing many of my models with my own homebrew draw functions that mimic the GLUT functions but apply the texture points according to what i wanted. Applying textures to GLUT objects is like playing the lottery. Who knows what you'll get.

GLUT isn't really helpful with the actual rendering end of things, IMO. Far too basic.

GLUT is more useful when using it to gather events from the operating system. It lets you focus a bit more on the GL code than code that sets up the platform itself.

But then again, with the Carbon Event Manager, it is just as easy to setup a rendering loop yourself and register for the Carbon events you want.

 

[Animalk]

GLUT is more useful when using it to gather events from the operating system. It lets you focus a bit more on the GL code than code that sets up the platform itself.

I forgot I was using GLUT for that as well. Thx for bringing it up.

 

[Cromulent]

Without specific examples of the limitations, it is hard to comment, but see if freeglut ( http://freeglut.sourceforge.net/ ) addresses them. If you really need a few widgets to help you out, have a look at GLUI ( http://glui.sourceforge.net/ ).

The problem with GLUT is that if I want to have a dialog box that opens before the application starts so that the user can pick resolution or choose windowed mode it is impossible to do (or so I believe).

The only way I know of to do this to use either Carbon, Cocoa or maybe even GTK+.

Thanks for the responses so far .

 

[stupidregister]

The problem with GLUT is that if I want to have a dialog box that opens before the application starts so that the user can pick resolution or choose windowed mode it is impossible to do (or so I believe).

I haven't needed to do this before, but I think you can. You can have the application create the dialog box in the beginning of the program. And then when the user closes the dialog box, you can then initialize GLUT and call glutMainLoop(), which starts GLUT's loop. The dialog box is created before GLUT is even touched, so I don't think there will even be a chance for conflict.

 

[Cromulent]

I haven't needed to do this before, but I think you can. You can have the application create the dialog box in the beginning of the program. And then when the user closes the dialog box, you can then initialize GLUT and call glutMainLoop(), which starts GLUT's loop. The dialog box is created before GLUT is even touched, so I don't think there will even be a chance for conflict.

You mean basically have a separate configuration utility that just writes the settings to a file which is then read by the main application? Or do you mean combining everything into one?

 

[stupidregister]

You mean basically have a separate configuration utility that just writes the settings to a file which is then read by the main application? Or do you mean combining everything into one?

I just mean have the code that opens the dialog box come before the code for GLUT (in main() ).