Here’s the deal. My game generates chunks of randomly generated terrain based on the position of the camera (2D isometric). When moving from chunk to chunk, there is always a tiny burst of lag which results in a little jump because the game must wait for the terrain to generate before it moves the camera more. From what I understand of threads, they could be used to have the terrain generate while the main thread moves the camera like normal. I am just not quite sure how to do this. Maybe something like this?
Update(){
if(cam != prevcam)
{
thread.start();
}
}
And then after the other thread is done with the generation it suspends itself somehow and restarts next time the camera position has changed. Note that the camera position refers to the chunk that the camera is centered on. If it was centered on block 40,42 then it would be 1,1
You could use threads to solve this problem, and it would probably work, but you’re going to introduce a whole set of problems that (a) might still result in lag, and (b) will be much harder to fix.
Don’t get me wrong, I love threads, but I wouldn’t use them to solve this particular problem, especially in a tight input/logic/render loop in most games.
The lag happens because the amount of work that needs to be done between frame renders takes long enough that you notice it as a dropped frame rate. What you really want to do is find a way to chop your terrain generation into smaller chunks/tasks that DO fit inside of a single frame render, and then spread terrain generation over as many frame renders as necessary to get it done without dropping the frame rate below what the user will notice.
To go a little deeper, I can see why you might be tempted to use threads to solve this problem. The thing is, threads are best when you’ve got a job for them to do, and you either don’t care so much about how long it takes for them to finish, or you really need two or more pieces of code to run simultaneously. In the case of simultaneously running code, threads aren’t always an optimal solution either; sometimes spawning a separate process, and leaving multitask scheduling up to the OS (the scheduler being a piece of code that has been highly optimized by tons of professional engineers) is often a better answer.
By introducing threads into your game loop, the thread’s work still needs to finish within a very small, well-defined time window, which means it needs to work in lock step with the rest of the app, which means there’s no benefit to running in multiple threads because you’re still acting like a single-threaded app.
The one exception to this would be if you really, truly need to take advantage of multiple cores. Just be warned that adding threads, while totally awesome, is going to add unnecessary complexity in most cases.
And after saying all of that, to answer your original question, you would use threads to do this by chopping it up into small chunks of work, and letting the thread work on those chunks as quickly as it could, without taking too much CPU time away from more time-sensitive threads, such as your rendering thread.
I’d like to see more games take advantage of threads. The issue is that most games are essentially simulations where almost everything is tied to a central clock (animation, sound, AI calculations, etc.), and removing that direct connection to the central clock can only be done when the user wouldn’t notice it. Examples of this might include:
Since threads don’t start/stop excecution execution in a known order, or within a certain time, it means sometimes it’ll take 1/10th second, but if the CPU is busy, maybe it’ll take a total of 2 seconds, with how available the CPU is.
Anyhow – good luck with your game!