So, I could make a really long story explaining everything about where I'm coming from, but here's the main question:
What's the common/best/usual method to make real-time games (empasis on the time aspect)?

I'm thinking of a way to do that, on the most abstract level:

loop indefinitely:
• find out the difference in time from the last loop
• tell everything to update their stuff based on that time
• draw the window

Does this sound good? Just wondering if there is some common way that every game runs. This is a rather specific question, so I haven't found a real answer to it...

http://sacredsoftware.net/tutorials/Anim...tion.xhtml

Ah, yes, exactly. Pretty much what I was thinking.
Now, the problem is, where do I loop it... I need to look into threads. =x

Back later...

No, you don't want to go near threads. What would make you think that?

One thread for inputs, one for updates?

I've got the main thread handling input method calls... glutMainLoop() called at the end of main(). That's normal for GL stuff, right?
The other thread, which updates and draws, is created via pthread_create(&threadA,NULL, runLoop,NULL); called right before glutMainLoop()...

The problem now is, this new thread calls glutPostRedisplay() to draw, and it has no effect called from the second thread. Since I can't get into glutMainLoop() myself and make everything in one thread, I've got a little problem here.

Ideas and simple solutions welcome, though I'm running around trying to get this to work myself...

Use the glut callbacks to get your events and other notifications called automatically on the main thread. No multithreading is required.

http://onesadcookie.com/Tutorials/

You have to be *very* careful with OpenGL and multiple threads. By and large it will just crash. GLUT + multiple threads simply doesn't work, and cannot be made to without calling an OS-specific function.

Exactly! I knew talking to real people would work better than google!

glutIdleFunc() is what I needed...

And I have a stick figure walking around with swords *smoothly* now!

OneSadCookie Wrote:No, you don't want to go near threads. What would make you think that?

How about a producer/consumer setup with object notification? You could lock and swap 2 sets of vertices and put rendering and physics in separate threads?

This guy is talking about the very basics of game programming. Yes, if you're writing an engine for a cutting edge game you'll probably want to deal with threads, but it's not a topic for this *ahem* thread.

If you want to start another topic about advanced game programming with threads, I'll be happy to discuss some options and theories