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?

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.

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?

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.

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?