   ai / physics within a glut program
  i have reached a point where i need to start considering how i'm gonna implement ai and physics into a project i'm working on.  however, since we are using glut, i'm not sure where the updating/calculating of those elements would go.  i noticed there is an idle function call back for glut, but it definitely doesn't seem to be the best place to do that stuff.  i had considered doing it in the display call back function, but since i'm using the timer call back to call the postredisplay() for a (hopefully) consistant frame rate, i'm not sure that is ideal either.obviously how well everything runs is completely dependant on how well the code for the ai and physics are written (speed optimized).  but, does anyone have specific suggestions?   
  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.   ;  that is honestly what i had considered -- the new thread.  however, i'm not too experienced with creating and managing threads.  do you by chance have any good references on the subject?   ;  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.   ;  yeah, c++.however, i have found that glfw actually has built in thread support.  so then it becomes just a matter of using glfw to start the thread and then not manually effing up the program by doing stuff that isn't thread safe.  :)   ;  The other thread was closed.  Cross posting is bad.  :PI'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.   ;  yeah, cross posting is bad.  i'm sorry for that.  this one just didn't get any response so i figured it was in the wrong board and so reposted it over there.  again, sorry for that.yeah, i am doing the input and rendering all in one thread.  then i figure there will be a thread for updating npc locations and for calculating physics.  but again, this is a very newbie idea.  if it isn't a good one, i'd be more than happy to hear a better one.  :)after looking at those links you posted (some of which i had seen before) i'm still as clueless as before as how to use them.  :-\  thanks for the links though!   ;  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:if (GLEW_ARB_vertex_buffer_object) {  // safe to use VBOs}Alternatively, since VBOs became part of the OpenGL core in version 1.5 (see here), you could write:if (GLEW_VERSION_1_5) {  // safe to use VBOs}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.   ;  oh, sorry about the unclear statement.  i understand how glew and glee go about loading the extensions, but then from there i have no idea what to do with them.  :)  i can mentally understand how they sound like great things but then i haven't taken the time to wholely understand what they are and how to use them.  i'm sure some day i'll get that figured out.thanks for confirming what i had thought about the multithreading approach!thanks for the help/input!   