Comments by RobD6 (Top 2 by date)

RobD6 30-Dec-10 13:56pm View

Hi Ted,

Thanks for the suggestion. I did a quick port to boost threads, but to be honest I'm not keen. It's much, much slower to build, results in a ton of compiler warnings, and while the interface is simpler and more portable, I'm likely to need some of the extra power of the native implementation that winbase supplies.

RobD6 30-Dec-10 13:46pm View

Hi Ralf,

Thanks for the response. There's definitely some stuff you've mentioned that I need to look into.

I think I didn't quite explain something properly though. The frequency of the update loop is very much faster than what I'd expect the render to go at. It's probably doing something like 1000 iterations a second. I don't want to render every iteration - the point of the mutex was to allow the much lower frequency main thread (containing the render) to break in and render when it wants to, but otherwise (most of the time) the sim threads will skip straight over the sleep and move on to the next iteration, since the draw thread isn't waiting.

If I understand your suggestions properly, I think they'd lock the render and sim loops together, which would massively affect the performance of the simulation. What I'd like to happen is for the simulation to go as fast as it possibly can, with the render happening at a regular frequency (say, 60Hz). What I should see on screen is a fast-forwarded view of the simulation.

Your answer has prompted me to look into how/when the draw gets called though - I think that may be part of the problem. I was assuming it gets called at a regular frequency, but it seems that might not be the case.

Thanks,
Rob.