Well, as I see it, there are two things you can do. You can either run your AI and physics completely apart from GLUT, using another timer callback or a separate thread, or you can do it within your display function so it's tied to the display frame rate. Personally, I'd favour the first way.

It depends what language you're using, as it's done differently in almost all of them. If you're using C++, then no, I don't know I'm afraid.

The other thread was closed. Cross posting is bad. :P

I'd recommend doing all your graphics and input in the same thread (I don't believe OpenGL API calls are thread safe - might want to verify this yourself). Since GLFW is restricted to one window, you don't have to worry about juggling multiple OpenGL contexts.

You're probably doing this anyway, I just want to make sure.

As for your other post:

Quote:
one last question -- what exactly are opengl extensions? i have looked at glew but didn't seem to see what it offered to me since i don't know what the opengl extensions are.

thanks for the input/help so far!

There are many places to get more information on OpenGL extensions, but to put it simply, extensions allow you to access functionality beyond what your base OpenGL version supplies. Later versions of OpenGL may include some of these extensions as part of the core API.

Basically, as you use more advanced features of OpenGL, you'll run into extensions. An example would be multitexturing, which, as you can see from the link, went from extension to part of OpenGL 1.2.

With GLEW, or alternatively GLee, you can check for the OpenGL version at runtime, and then you know what base functionality you've got. For instance, if you check for OpenGL 1.2, you know you've got multitexturing available. You can also check to see if multitexturing is available specifically (without checking the version), and this is what these two libraries do for you.

For more information, try the newly created OpenGL wiki or OpenGL.org.

Decoupling physics from the framerate (rendering) sounds like a good idea to me. Not newbie. Same with A.I. and npc locations.

If you find yourself using way too many mutexes, and your multithreading code becomes fraught with race conditions and other synchronization problems, you might consider rewriting some of that code as a single thread. You'll get a feel for it as you do more parallel programming, and so this may seem like pretty obvious advice.

As far as extensions go, are you asking how to use the extension loading libraries, or how you use OpenGL extensions?

For the former, both GLEW and GLee have simple examples on their sites.

For the latter, as I said before, you'll run into them as you need them, or discover them.

For instance, at some point you might want to store your vertex data on the graphics card (as opposed to system memory). There's an extension called Vertex Buffer Object that lets you do just that.

In GLEW, you can check if this extension is available by doing:



Alternatively, since VBOs became part of the OpenGL core in version 1.5 (see here), you could write:



There are many places to get more information on VBOs, but don't discount the VBO spec itself just because it's a specification; it has quite handy usage notes and sample code.

Note that the NeHe and DevMaster tutorials get the extension function pointers manually (that is, the functions you call to use the extension), which you don't need to do if you are using GLEW or GLee (it's why these libraries are so handy!). You can simply start using vertex buffer objects after checking their availability.