Most basic real-time app programming

Nibbie
Posts: 1
Joined: 2008.11
Post: #1
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...
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Nibbie
Posts: 1
Joined: 2008.11
Post: #3
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...
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
No, you don't want to go near threads. What would make you think that?
Quote this message in a reply
Nibbie
Posts: 1
Joined: 2008.11
Post: #5
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...
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #6
Use the glut callbacks to get your events and other notifications called automatically on the main thread. No multithreading is required.

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
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.
Quote this message in a reply
Nibbie
Posts: 1
Joined: 2008.11
Post: #8
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!
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #9
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?

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #10
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 Smile
Quote this message in a reply
Post Reply