I've seen Civ V at a friend, he had a pretty recent PC, and it didn't exactly fly. Didn't look any faster than previous versions, maybe even a bit slower. So they probably barely managed to keep a constant speed in light of new features. Apart from water (which is soo useful in a sim game), what other features did they add that ate up that much CPU? Opponent AI?

While it's not crazy fast, it's perfectly playable on my Thinkpad (Core2 Duo 2.4Ghz, 4GB RAM, Radeon 3650, 256 MB, DX11). I even put up almost all graphics settings to max.

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 :).

Try playing on a Huge map :)

End-game means 20-30 seconds wait for turns to complete, even on a Core i7.

There are major slowdowns when running the game in DX10/11 mode on some hardware, especially when scrolling the game map. It is likely that you saw this - when I run it in DX9, it is buttery smooth. In DX10/11, it stutters unbelievably. There was a patch recently which may have fixed the issue, but I haven't played since the game got updated.

Non-PDF link: http://docs.google.com/viewer?url=http://a676.g.akamaitech.n...

Has anyone used both Intel's Thread Building Blocks and Apple's Grand Central Dispatch? GCD is focused around adding blocks to C and managing dispatch queues.

Anyone have pros and cons of both frameworks?

GCD is separate from blocks; you can use one without the other. GCD/libdispatch is a library written for concurrent execution and to make it easier to manage. Blocks are closures added to C, Objective-C and C++. Lambda's have also been (or rather, will be) added to C++, in C++0x.

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.

There was a session at WWDC 2009 given by a couple of Intel engineers comparing the two. (Session 131, if you have access.) In their benchmark - parallel pipelined face detection - they were within about 1% of each other. GCD scaled up to more cores slightly better.

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 recently purchased C-IV. I prefer not to have other players; People who play much better than I tend to take over my game. I kind of struggling through. In a way I'm glad that it rolls a little slow. I'll have to agree it is a little slower than the previous versions. It will be a while before I will even touch C-5. But that's okay because I only have a few hours to play the game during the night anyway.

What I would love to see is a comparison of CivV and the modern design with the design decisions made by Stardock on Galactic Civilizations which game out for OS/2 in the mid 90s. At the time, it was pushing the barrier for turn based game AI.

I do miss that game...unfortunately even their remake in 2003 only targeted Windows rather than Mac/Linux.

I've myself been doing an awful lot of multi-core programming recently so I can appreciate the effort that goes into building these kinds of systems/applications/games. One things for sure, asynchronous and multicore programming is the biggest new challenge facing us as programmers and the programming tools are just starting to realize it.

All that work just for the water! Impressive. That's also helpful for when it comes out on Mac: I'll know what to disable first to cut down on power usage when mobile.

So next time - please design it for single-core.

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.

Last slide summary:

- 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