As he said, it's very difficult to write a well threaded game, there's tons of synchronization that needs to take place, and it becomes debugging hell. I don't know about HL2, but with Doom3 originally they had planned to have the rendering running on one thread and the physics and sound each running on separate threads, but during development it was a nightmare to code and they eventually gave up because of too many synchronization problems between the threads. They ended up with one thread for sound (which accounts for very little cpu time) and everything else in the other thread.
The problem is that usually the tasks you're doing aren't easily parallelizable. You've got to receive all the input before you can run the next frame,and you've got to run the frame before the renderer can render that frame. Similiar with physics, you could easily thread it if all the objects only interacted with the world, but since they can potentially interact with each other, you can end up with a lot of problems. Sure you can have different threads running different tasks, but typically the other threads are going to be blocked waiting for the previous thread to finish its processing for that frame so that the next thread can start its processing for that frame. Since nothing is running in parallel then, you don't get any advantage from using multiple threads. And thats assuming the code is written correctly, which isn't exactly a cakewalk :) On 8/8/05, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > Damien wrote: > > > > Maybe the Valve developpers may think about Thread implementation, to let > > coders use threads in their mods/plugins. Because the first problem I've > > found for thread coding is that thread implementation in linux and windows > > are VERY different... So if the engine could give some Thread > > primitives, it > > may be better (I mean thread_start, thread_stop,thread_yield, and basic > > mutex functions)... > > Threads in games are REALLY hard to do properly. Game developers > working on next generation consoles (Xbox360, PS3, etc.) are spending a > lot of time and effort trying to create game engines that will handle > multiple threads (and/or multiple processors) efficiently. It's > difficult to take what has always been a sequential sequence of events > (get input, move objects, render frame, repeat) and make threads or > tasks that divide up this work without spending a lot of extra time > trying to synchronize things between processors or threads. It seems > like it would be a simple task to just make separate things run on > separate processors, but there is quite a lot of inter-dependency > between things in the world, so many times you can't perform > calculations on thing A until thing B has been updated, and thing B may > depend on thing C and D, etc. > > Not only does the creating of the code become much more difficult, but > the debugging of the code becomes a nightmare (because you pretty much > need a separate debugger for each thread or processor). > > -- > Jeffrey "botman" Broome > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
