> I would tend to disagree. If you rewrite it from scratch, why > shouldn't > you be able to benefit from concurrent execution?
It might benefit. I just don't think that a significant portion of the processing load could be done concurrently...maybe it could. Maybe spawn a thread to handle the processing for each client connection. Maybe break up the engine into X number of sub engines, each being a thread dedicated to each player. A new "sub-world" thread would be created for each player, and they would then all communicate with a "whole-world" master process. I imagine this would require a few man-years of design and programming though... > Yes. :) Okay, not really, actually I think they just went the easy way > and didn't want to go through the tougher design phase to make it > concurrent. I doubt this was the reason. More likely is the fact that at the time they were writing/designing this engine, windows 9x was the dominant platform (still is, last figures I read). Very few people were running NT, and they hadn't even thought of a Linux port. That came a few years later. And win 9x obviously doesn't support preemptive scheduling (a requirement for threading), nor does it support SMP. Recall that Half-Life came out in, what, 1998? Windows 98 wasn't even out yet when HL hit the market. And almost no one was using NT for games, due to lack of DirectX support. StanTheMan TheHardwareFreak http://www.hardwarefreak.com rcon admin at: Beer for Breakfast servers <http://bfb.bogleg.org/> 209.41.98.2:27016 (CS multi-map) 209.41.98.2:27015 (DoD) 209.41.98.2:27017 (CS militia/dust2) Dallas, TX _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
