To use GLUT or not?

I've finally managed to get OpenGL working (yes! - OpenGL, C++ and Glut – Using CodeBlocks and MinGW « Codie Code if anyone is interested).

Now I can't help noticing alot of anti-glut attitude - but I can't find anything in searches about the overall problems and solutions to GLUT.

Before I really start learning OpenGL, should I use something else? Because if GLUT isn't worth it in the long run and something better is available then I may aswell get used to the alternative from the beginning. I am programming on Windows (because I don't have any other choice right now) and I am using C.

So should I use GLUT and why, and if not - what are the alternatives?

Quote:

---

Before I really start learning OpenGL, should I use something else? Because if GLUT isn't worth it in the long run and something better is available then I may aswell get used to the alternative from the beginning. I am programming on Windows (because I don't have any other choice right now) and I am using C.

So should I use GLUT and why, and if not - what are the alternatives?

---

Well, here are some great GL tutorials if your interested - NeHe Productions: Main Page

I think GLFW or SDL are better than GLUT. GLUT is kinda old. SDL is, too, but it is really good. GLFW is designed specifically for OpenGL and like a better GLUT.

Of course you could also go with windows.h/MFC. And/Or Direct3D.

Quote:

---

Originally Posted by Jake.c

Before I really start learning OpenGL, should I use something else? Because if GLUT isn't worth it in the long run and something better is available then I may aswell get used to the alternative from the beginning.

---

I don't know if all these options are comparable, eg, SDL and GLUT. For starters, SDL material is usually C++ and involves more than just OGL, whereas GLUT is C and just some simplifying wrappers for OGL.

The reason I put "the alternative" in red is because the alternative is not to use any of them; you use just your platform specific API -- eg, on linux this would be GLX and on windows I think it's called wiggle. The whole point of GLUT is to save you some lower level tasks dealing with the OS windowing system, and focus on the actual graphics programming. There is a performance trade-off there, so when you are comfortable with the graphics programming and you start to want better performance (which it will not matter at all to begin with), you can stop using GLUT as a crutch and work the OS interface directly yourself*. The graphics side of it will remain the same, so by using GLUT for a while, it is not as if you will have to "relearn" anything later -- you are just leaving more to learn for later, which you have to do that one way or another. By using GLUT, you are choosing to focus on one thing first, which is probably necessary since you may need some practical experience with OGL before you start dealing with platform specific issues manually -- or, at least, those issues will be more meaningful to you if you just chill out and use GLUT for a while.

So "the long run" is: you learn the basics with GLUT, and then you go from there. An advantage to GLUT over anything else is it is very simple, so you really do not have to invest much in it, which is good because initially you should put all your energy into OGL itself. The extent to which you become dependent on GLUT's features is up to you; all the GLUT functions are prefixed "glut" (nb, "glu" is part of OGL proper) so you can always tell when you are using a method specific to it. Mostly, those are for 1) managing the window and UI, 2) managing an event loop. There are a few GLUT things for rendering simple objects, but you do not have to use those functions at all if you prefer to "do it yourself".

Hope that helps.

*Of course, that also means GLUT adds some significant portability, if that is actually a concern.

Hmmm I guess I'll go with GLUT for now then.

I'm trying hard to stay away from anything win32 api - Every single windows api tutorial I've followed has always had a "Don't worry about what this bit does, just put it anyway because you don't need to know" - that just makes me feel like I'm not actually learning anything - memorizing instead of learning.

GLUT tutorials don't tend to do that so much.

Still, GLFW is very similar to GLUT. And I think a bit more comfortable - a single init call instead of ~5.

EDIT: Totally agree. I hate that. Those should write _references_, not tutorials. But that's not specific to windows.

Quote:

---

Originally Posted by Brafil

Still, GLFW is very similar to GLUT. And I think a bit more comfortable - a single init call instead of ~5.

---

Never heard of GLFW before. It sounds good. I notice it "does not lay claim to the main loop", which may explain why it does not require as much initialization. Altho, looking at the manual, I think you are fibbing a bit -- there is only one init() call, but then inside the main loop -- which is just while(1) -- there are 3 or 4 more glfw calls to swap buffers appropriately, etc.

Only use a high level wrapper for a low level API if you understand the low level API.

Also, I would like to get a book (tutorial/guide - not reference) for OpenGL.

Does anyone have any experience with "OpenGL: A Primer" by Edward Angel? - It looks like what I'm looking for.

Thanks everyone for their views, I'm going to give GLFW a little try but will fall back on GLUT if that fails.

Quote:

---

Originally Posted by Jake.c

Does anyone have any experience with "OpenGL: A Primer" by Edward Angel?

---

I don't, but if it looks good to you try it. I have the SuperBible and I had the red book out from the library for months, and while they are both (over?) packed with material, neither one is particularly well organized and the conceptual/editorial quality is like mediocre - okay IMO. So I can't say "Oh gosh, you have to read the RED BOOK! It's awesome! Insightful! Interesting!" cause that would be a lie.

OpenGL deserves a good book; I'm not that into it but I could still think of a lot of possibilities that I'm sure have not been exploited in this regard. I would say the ostensible topics of "A primer" are good choices:

Quote:

---

Two-Dimensional Programming in OpenGL, Interaction and Animation, Basic Three-Dimensional Programming, Transformations, Lights and Materials, Images, Texture Mapping, Curves and Surfaces

---

That's gonna take anyone months (I'd even bet at Christmas time you may still be looking forward to "Curves and Surfaces") so it's not you will quickly outlive the book. There is a lot of support for openGL on line so you don't need to depend on it for everything.

Plus you could try a used version of the 2nd edition on amazon for $5.

Yeah, here in the UK most programming books are £30+ - this is £15 new. So second hand for even less, I can't really go wrong can I? There's always the red book to fall back on (the old online version).

On that note, is it true that Microsoft stopped supporting opengl at some point? OpenGL 1.1? If so, does that mean for me (only have access to windows), any book documenting OpenGL 1.2 or above would be useless for now?

I have read this somewhere.

me too................

Quote:

---

Only use a high level wrapper for a low level API if you understand the low level API.

---

Or you're lazy ;-p

Closed. Thread is too old and latest posts add nothing to it's content.