Would you guys suggest using GLUT, or not? I don't really like how GLUT takes control of windows and other such things, when I really want Cocoa to stay in control of that. Anyone have anything to say in the matter?

The only reason to use GLUT is to have it do all the work for you. If you can live with the very basic events and GUI features it gives you, you can have an app set up and start working on your real graphics code in under 5 minutes.

You're not really supposed to use GLUT's GUI toolkit as part of a larger application; it's meant to be the skeleton. If you're already setting up a window and handling events, you have no need for GLUT at all.

I'll always start with GLUT, simply because it's so easy to get to the core of things.

If I need something GLUT doesn't provide, like decent keyboard input or decent mouselook or a list of available display modes, I'll switch to a more fundamental API.

Try SDL. I found it to be much more open ended and less constricting than GLUT (that was hell). Plus, if you want to use cocoa to control stuff as well, you probably could, considering that the OSX implementation of SDL is based on Cocoa itself!

I've used GLUT and SDL, and SDL is easier to "insulate" from your code, so you can change your mind later without having to change your code a lot. The only thing I don't like is SDL's windows resizing and full screen handling. It forces you to create a new context, and you lose all your textures. Besides, GLUT's window resize is much smoother. But, in general, I still prefer SDL.
(BTW - maybe there is better way to resize in SDL, if anybody knows please tell me! )

PowerMacX Wrote:But, in general, I still prefer SDL.

I prefer neither. I guess I am a control freak.

FCCovett Wrote:I prefer neither. I guess I am a control freak.

If I'm making a Mac only app or game, I use mac-only stuff too, but I'm still a little pissed off by all the time I wasted learning how to use DrawSprockets & InputSprockets, QuickDraw, the MemoryManager and a lot more "now useless" stuff!!

I hear you. It's really frustrating to put so much effort on learning stuff that's going to be called legacy in less than five years or so.

PowerMacX Wrote:I'm still a little pissed off by all the time I wasted learning how to use DrawSprockets & InputSprockets, QuickDraw, the MemoryManager and a lot more "now useless" stuff!!

Aren't we all

Ok, so I am a little confused. Which is the best library to use? Say one were creating a vast 3D world. Which do you think would be better for handling basic functions? Should I go with SDL or GLUT. I've been doing a bunch of tutorials on GLUT, and found them really straight forward, however this thread has placed doubt in my mind as to its functionality at higher levels. Any Ideas?

start with GLUT, 'cos it's easiest.

if/when you need more, switch to something better. SDL may or may not be that "something better"; it has its own limitations.

well... I don't want to get 80% thru my programming and then have to convert all my massive code. Can you suggest something that many/most major game developers use? (as far as OpenGL/C++).

EDIT: Also, could you give me an example under which either SDL or GLUT would fall thru in regards to functionality, performance, or robustness?

Volte Wrote:well... I don't want to get 80% thru my programming and then have to convert all my massive code. Can you suggest something that many/most major game developers use? (as far as OpenGL/C++).

The conventional way to deal with this issue is to ensure that your game code doesn't depend on anything about the application framework you're using. For example, don't pass SDL_Events directly to your game objects, convert them into a data format that is specific to your game, and only allow your game code to access its own data formats. Then, if you decide to change the framework you're using, you only have to change the wrapper code.

There's no escaping that you have to do some work when you switch application frameworks, but you can certainly minimise the effort this way.

Quote:EDIT: Also, could you give me an example under which either SDL or GLUT would fall thru in regards to functionality, performance, or robustness?

I haven't used GLUT enough to comment, but SDL is limited in that it can only support one window/screen, it doesn't provide any reasonable way of putting up a GUI using standard OS features, and in general it's hard to make your game feel 'Mac like'. You'll probably also want to use some extra libraries such as SDL_image, SDL_mixer/OpenGL to get better image format and sound support. (I believe GLUT doesn't have any sound support at all.)

Those things aside, SDL is pretty good.

SDL is great; window stuff aside, it already has image code, sound code, endian code, reading/writing code, etc, built in.

endian code, oops. I had to write my own a couple weeks ago because I didnt know that.
How do you acces the endian code?