# ai / physics within a glut program

This topic is 4414 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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?

##### Share on other sites
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.

##### Share on other sites
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?

##### Share on other sites
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.

##### Share on other sites
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. :)

##### Share on other sites

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.

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.

##### Share on other sites
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!

##### Share on other sites
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.

##### Share on other sites
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 the help/input!

1. 1
2. 2
Rutin
25
3. 3
4. 4
JoeJ
18
5. 5
gaxio
11

• 14
• 22
• 11
• 11
• 9
• ### Forum Statistics

• Total Topics
631766
• Total Posts
3002215
×