Sign in to follow this  
Mike.Popoloski

Threads

Recommended Posts

Up until now I have mostly steered away from the whole threading topic, but I have come across an area where it may be useful. My situation is this: I am using an infinite terrain system, where each frame I check to see if I need any new terrain blocks because the user has moved. If I do, I generate those new terrain blocks using a variation of Perlin Noise. The problem comes with generating these blocks, as there is a tiny pause whenever a new one is generated, which at the fast speeds that the user will be moving at causes the game to feel jerky. I believe I have gotten the generation down as fast as I can, and my profiler tells me that my problem is just my noise function ( which is expected ). Now, I was wondering if implementing a threading system, where one thread is devoted entirely to the production of these terrain blocks, would help my situation. I am not sure of the speed benefits, as I have never used threads before. Any suggestions?

Share this post


Link to post
Share on other sites
If the player moves in such a way that the generated area must become visible before it has been fully generated, then you will still end up having to wait -- and in fact, you will have to write your code in such a way that you detect that case and actually do wait.

Otherwise, yes, threading may help eliminate that pause, assuming you take care of initiating the generation early enough that the area doesn't become visible until it is fully generated.

Share this post


Link to post
Share on other sites
Thanks for the reply. So, would it be possible for the terrain thread to first generate all the terrain blocks around the player, and then if it finds it has extra time ( like if the player slowed down or the terrain generation didn't take that long ) then it could just spend its time working on generating blocks further away that the player hasn't reached yet? At what point does the terrain thread slow down the other thread, if ever? Should I just have the terrain thread go wild and just keep generating blocks?

Share this post


Link to post
Share on other sites
Quote:
Original post by ussnewjersey4
At what point does the terrain thread slow down the other thread, if ever?


If you only have one CPU (or, nowadays, one core) on your system, then running two threads will necessarily make both threads slower: when the CPU is executing one thread's code, it is not executing the other's. You only have so many resources, and they are split between all the processes and all the threads that are running on your computer.

One exception is when one of the thread is waiting (e.g. on I/O), in which case it consumes almost no CPU time.

Quote:
Should I just have the terrain thread go wild and just keep generating blocks?


No. If anything, you may run out of memory. [grin]

You need to compare the time it takes for your system to generate a block with how far the player can move and see. Then you need to keep in memory a set of blocks sufficiently large that the player will never see an ungenerated block. As the player moves, you generate new blocks in the direction he moved, thuse preserving the "buffer area" of generated blocks. And, when necessary, you can start dropping the blocks that have fallen back sufficiently far away from the player.

Share this post


Link to post
Share on other sites
Of course all that might make things perform worse. You'll be generating more blocks than before, many of them unused since you're doing speculative block generation. Then add into thread swap overhead and synchronization overhead. Remember your trying to add an extra thread that all it does is work on a CPU bound task. That's not really a recipe for success unless you know there's a second processor/core available.

Share this post


Link to post
Share on other sites
Once again, thanks for the fast reply.

Quote:
No. If anything, you may run out of memory.

Of course, my system already drops blocks that are too far from the player. :)

Quote:

You need to compare the time it takes for your system to generate a block with how far the player can move and see. Then you need to keep in memory a set of blocks sufficiently large that the player will never see an ungenerated block. As the player moves, you generate new blocks in the direction he moved, thuse preserving the "buffer area" of generated blocks. And, when necessary, you can start dropping the blocks that have fallen back sufficiently far away from the player.

My problem is not that the player gets to see ungenerated areas. As of now, there is a "buffer area" around the player, so all he can ever see is generated terrain. The problem is that as the player moves, new blocks are generated. Even though they are at that moment too far away to see, the player still feels the impact of the block generation because the entire system has to wait until the block has been generated, and while it only takes a fraction of a second, that little bit makes the movement jerky.

Quote:

If you only have one CPU (or, nowadays, one core) on your system, then running two threads will necessarily make both threads slower: when the CPU is executing one thread's code, it is not executing the other's. You only have so many resources, and they are split between all the processes and all the threads that are running on your computer.

So even if running two threads slows down the game a bit, it would still eliminate the jerk each time a block is generated because the rendering loop can just keep on plugging without having to wait for the block generation, correct?

If so I believe I will try to implement a basic threading system. Do you have any links or tutorials on the subject?

Share this post


Link to post
Share on other sites
Quote:
So even if running two threads slows down the game a bit, it would still eliminate the jerk each time a block is generated because the rendering loop can just keep on plugging without having to wait for the block generation, correct?


Yes. If you do extremely heavy processing in one thread you can screw up the ability of your OS to simulate multithreading on one processor, but what you're doing won't even begin to come close to that.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this