   Reasons to use threads.
  What are good reasons to use a seperate thread in a game? In the space sim I am working on at the moment I was considering using a thread to generate procedural planets in the background, while the player flys towards them. But then I realised I couldn't think of a reason to do it like this instead of just creating a bit of the planet every frame, during the game loop. Threads in Windows are not particularly flexible as far as priorities go, so surely in games its always better to manage time slicing yourself. But then I have heard of plenty of games that use seperate processing threads. Whats the deal?   
  if you have a low framerate you also have a low input rate ...mb your game doesnt realize that a key was pressed ... the player wont like it ...by using a seperate input thread you garantue that theres enough input ...sleep the thread some millisekonds in order to give the others more time ...but with using threads you have to synchronize resource access ...( writing and reading at the same  time, into the same region can cause trouble )   ;  What 'frame rate' does one need to capture input at? Most games are unplayable at less than 25 fps anyway, so the input messing up wouldn't be the main problem surely? P.s. I do have a fair amount of experience in thread programming, but for 3D editing apps, not games.   ;  I think it's quite apt that 'Thread' rhymes with 'Dread'. GENERALLY speaking, threads are more hassel than they're worth, and most games up until now have been single threaded. But now we're being forced to write multithreaded apps because of things like the Xbox 360 and PS3, and obviously dual cores. Physics is quickly becoming a seperate thread, where you get a physics system running constantly in the background that keeps updating objects on a constant basis, and when you're ready to draw you just say 'Where's my stuff?' and draw it at the current position. It means you can get really accurate physics by simply giving the thread more priority. Which is cool.Personally, I hate threads, they are root of all evil. I was doing on somthing at work which was going ok, until threads reared thier ugly fat head and ruined it all. But, get used to it, cos the little buggers are here to stay.   ;  is that right that win32 multithreading, uses more than one cpu if available?( in your words it seems so )i doubt, because threads have to same adressspace as there parent process ...but another process hasent ... at least it think soto create multicpu-using programms you need to create more than one process ( everyone with its own address-space ) ... with using mpi,openmp or whatever you can distribute information from one to the other ...but if its right what you said, why using MPI, openmp, ( and a couple of others )to parallelize programms( i have no dualcore at home ... but i have acounts one MP machines ... so im at least not totaly new to parallel programming)[Edited by - ronnybrendel on December 6, 2005 6:08:02 AM];  So whats the deal with input and generating procedural content in the background? Use threads or not? I can't see any reason to. Anyone got any experience one way or the other?   ;  If you don't plan to take advantage of duel core/proc then don't worry about it and keep it simple. Even if you do, I would never do input in a seperate thread.   ;  Sounds good to me! I love the idea of threads, but hate the actuality, so suits me fine to not use them.   ;  One thing i have heard of is using other threads to deal with background resource loading (think very large worlds in a MMO).Loading a file will stall your game if you don't use another thread. Thus the wonderfull loading screens, and how they update in increments.But a second thread can load in data for streaming audio, streaming video and streaming levels all without stalling your main thread.   ;  Yeah that makes sense, but one could still just load a bit of data at a time in the main thread, and that shouldn't stall anything.  I would guess the reason loads stall a game usually is that a large amount of data is being loaded in one API call, which takes a while to return (like freading an entire image in one go). An API call to read a few bytes would be virtually instantaneous I would have thought.