How Civilization V was built for multi-core processors [pdf]
a676.g.akamaitech.net
a676.g.akamaitech.net
About the only time when rendering is really slow is in diplomacy view with dude that has fires in the background and air shimmering full-screen pixel shader (Aztecs?).
Where it is noticeably slow is AI computing when finishing your turns (mostly towards the end of the game, when there are many units). But hey, it's turn based game, so it's not that bad :).
End-game means 20-30 seconds wait for turns to complete, even on a Core i7.
Anyone have pros and cons of both frameworks?
I've never used Intel's TBB, but it looks like it is similar to what libdispatch's purpose is. Of course, I could be way off base. But, I don't think I am.
Because it was initially built for TBB, they had to use some additional logic when moving to GCD so that frames would be rearranged into sequential order before certain stages.
I do miss that game...unfortunately even their remake in 2003 only targeted Windows rather than Mac/Linux.
On a 3GHz core2quad it fails to work smoothly in the endgame. The graphics are nice, but how can 640MB video memory be not enough to hold tiles at medium quality?
Physics? Particles? On a separate CPU core? It's Civilization, those things should only appear as researchable-items in the game. It seems that while pursuing parallelization someone forgot to check how it works alltogether.
- Can’t just thread systems, have to design them well first
- Don’t stick serial points just to make old serial code safe, write new code!
– Any serial point is bad (mutexes, critsections, spin locks)
– Decoupled systems easier to maintain