2 Threads C++ Win32 + OpenGL = Performance Problems

Started by
6 comments, last by ajm113 15 years ago
I created a thread system that passes values to the main thread and the main thread passes values to the Particle thread system. Lets say a for loop of 20 for calculating where the particle will be next in world position in the particle thread is only going on. Then I do a for loop in the main thread of the 20 particles to render the pixels. Pretty much these two threads are passing variables fine and dandy, but it seems I get these 2 problems. 1. Some particles go faster and slower then others in the particle thread. -Though I did make a double variable holding my TimeDelta which gets passed into the particle thread class every Frame. So when the particles move for example 0.11 it will also get multiplied with my TimeDelta, so the particles should move slower or a bit faster to keep up with the time, just encase the computer was fast or slow with performance. 2. It causes lag to the main thread. -Now I'm not sure if the for loop in the main thread is slowing the game down a bit. Which gets the particles being used from the Particle thread class which would only loop 100 times only rendering a point in OpenGL for each particle position. How do game companies avoid these performance problems with handling threads that do work for Particles or Physics calculations for example then render the object in the main thread? A question more simplified and more of what I want to figure out if you didn't understand my long question.
Check out my open source code projects/libraries! My Homepage You may learn something.
Advertisement
How do the two threads communicate?
How do you keep the two threads in synch (so that the particle thread only updates the system once per frame)?
What does the main thread do while the particle thread is working?
Quote:Original post by Hodgman
How do the two threads communicate?
How do you keep the two threads in synch (so that the particle thread only updates the system once per frame)?
What does the main thread do while the particle thread is working?


I already know how to pass variables around. It's how two keep threads in sic, pretty much with out effecting the particle's movement appearing too fast and or too slow.

The main thread does everything. (Game Input, Rendering, Audio(Fmod), Pitch Detection, Block Spawning & Calculation For The Blocks)

I'm making a update for my game, So it runs faster with more Rendering and calculations.
Check out my open source code projects/libraries! My Homepage You may learn something.
Ok... I don't know how you pass data between the threads or how you're trying to keep them in synch, so I can't help you with that directly. Here's some general ideas instead:
buf1 = enough memory to store the particle system's state. Needs to be lockable.buf2 = another buffer of the same size. Doesn't need to be lockable (no mutex).currentTime = global volatile timer/counterThread #1:init particle system in buf1copy buf1 into buf2start Thread #2currentTime = 0;while true //main loop currentTime += delta time.. update game render game lock buf1 render particles in buf1 unlock buf1end whileThread #2:localTime = 0lastCopiedTime = 0while true //main loop if localTime < currentTime //main thread has advanced a frame, we can update now  localTime = currentTime;  update particles in buf2 end if if lastCopiedTime < localTime // main thread's copy of the data is outdated  if can lock buf1   lastCopiedTime = localTime   copy buf2 into buf1   unlock buf1  end if end ifend while
You can implement a particle system in the main thread, there is no reason why you should have to run two threads to do this task, especially since you are synchronizing data so frequently between both contexts.

Furthermore, a single threaded approach here would reduce complexity, development time and debugging time.

Remember, keep it simple.
Quote:Original post by Hodgman
Ok... I don't know how you pass data between the threads or how you're trying to keep them in synch.


That's pretty much what I have.

I use a class with public functions and a class pointer variable in the cpp for the class's functions to collect values as a global variable for that cpp file.

Then in the core of my game engine when the game starts I call the thread which does a while loop for the particles. Then for every frame I created a function which takes the GameDelta time and then it updates the pointer of the Particle class for the thread.

Is there a way to tell the thread to wait until for example a part of my main while loop is done rendering the frame?

@cmroche

1. Particles take a lot of time to calculate with hundreds of them with much going on at once.

2. The main thread is already having a bit too much to do with out getting lag from the pitch detection system and calculating the blocks while the same time the models and world around you is moving.

3. Even looping 20 particles already has increased lag a lot at certain points of the game in the main loop.

I can't really keep it simple if even the main thread can't even handle what I want it to do.
Check out my open source code projects/libraries! My Homepage You may learn something.
Quote:Original post by ajm113
Is there a way to tell the thread to wait until for example a part of my main while loop is done rendering the frame?
The code I posted does that (via busy wait) using the shared variable 'currentTime'.
Oh, I see sorry, I was having a headache and I guest I wasn't really looking at it.

It looks that it works, I'm guesting the very small jitters are from the while loop rendering the particles and a few others, but I'll get another thread underway for the pitch detector since that as well takes up 1-2 milliseconds to calculate.

The method seems to slow down my particles dramatically, but I think I can increasing speed if it doesn't become too much of a problem on other PCs.

Thanks, Ajm.

[Edited by - ajm113 on April 19, 2009 2:14:46 PM]
Check out my open source code projects/libraries! My Homepage You may learn something.

This topic is closed to new replies.

Advertisement