Quote:
Originally Posted by dduff442
Hi All,
Will SoW:BoB take advantage of 64-bit, quad-core architecture, hyperthreading etc?
The PC gaming industry has gotten seriously out of whack. $800 twin-gpu setups are common, but no more than a tiny handful of games use more than 2 CPU cores, more than 2GB of ram or are multi-threaded. A great opportunity for deep AI and immersive, interactive and open worlds is being totally ignored by the industry. This is all the stranger as RAM and CPUs are relatively cheap compared with high-end graphics cards.
I'm hoping SoW:BoB will make use of the PC features that will be mainstream in the coming years. FSX is the only game that does at the moment (seriously, this is a fact). SoW:BoB is ideal for hyper-threading and the 16GB of RAM the Home Premium editions of Win 7/Vista allow would permit environments of incredible detail to be portrayed, along with intensive layered AI processing etc.
There's a lot of expectation out there for BoB, and I'm no different. I held off buying a new PC until it became imminent. (I'm very reassured at the busy look of your offices BTW!) A bit of info about the processing capabilities of BoB at this point might whet people's appetites even more....
Regards,
dduff442
(have played online as Kestrel666) |
Well, you describe the "strange" scenario well above - how come that so few games use multiple cores effectively but rely on beefy GPU:s? I guess you are not a programmer? It's really hard to use many threads effectively in an application that uses a main render loop that runs the screen updates at very high steady speed (many threads doing the render is even worse - though in some cases possible). When you are going to synchronize/join data for that render thread with a number of separate other threads (AI, network, loading stuff etc), you will have to keep you tounge in the right mouth
The threads running on different cores really live their own life (and should do so) so the syncronization has to be effective to not get threads waiting for other threads etc (producing stutters and lag). Getting a bunch of threads to dance together while the main render thread runs at a steady 60 loops/sec is like a tango with four wifes - without annoying any one of them
EDIT: It's naturally a grail to be able to be able to write the optimal game engine using all cores available in a system... Even writing a game that runs two threads well can break programmers and companies backs - F4/Microprose anyone?