System requirements...

[borad]

I imagine Civ V will heavily use Grand Central Dispatch for massive multi-threading

 

[civ_king]

GCD is a system set up that allows the coder to make threads easy, if the coder knew of 128 threads they needed it could be done in less than an hour. Because of how integrated this is into Snow Leopard Civ V Mac might be able to scale far better. Also Aspyr knows that many Mac users have a quad core or greater (e.g. every Mac Pro ever made).

 

[borad]

Just that on my brief experience with Civ V on Windows I saw little evidence of more than one (full) core being used, despite the promises before the release.

Since one of the big delays later in the game seems to be workers evaluating every hex their civilization owns (and probably a few more), I guess there's potential for improvement… just put me down as skeptical it'll happen!

 

[civ_king]

Just that on my brief experience with Civ V on Windows I saw little evidence of more than one (full) core being used, despite the promises before the release.

Since one of the big delays later in the game seems to be workers evaluating every hex their civilization owns (and probably a few more), I guess there's potential for improvement… just put me down as skeptical it'll happen!

Many people report it using two cores, but [Platform trolling is banned]

 

[crag]

10.6.5 (the latest) included some major updates (and fixes) to OpenGL. The patch notes are available at Apple if you want details.

If you play Warcraft, you already know this. Since 10.6 has made that game playable now. Warcraft had a major update that caused havoc with Windows and Mac users.

So update your OS folks. Also 10.6 has much better graphic support then Leopard. Why SL is required by most games now.

But, does anyone know if the game is 32bit AND 64bit? Or just 32bit?

 

[civ_king]

10.6.5 (the latest) included some major updates (and fixes) to OpenGL. The patch notes are available at Apple if you want details.

If you play Warcraft, you already know this. Since 10.6 has made that game playable now. Warcraft had a major update that caused havoc with Windows and Mac users.

So update your OS folks. Also 10.6 has much better graphic support then Leopard. Why SL is required by most games now.

But, does anyone know if the game is 32bit AND 64bit? Or just 32bit?

All Intel Macs are 64 bit except Core Duos. And those don't meet minimum spec. I think it will only be 64 bit

 

[crag]

All Intel Macs are 64 bit except Core Duos. And those don't meet minimum spec. I think it will only be 64 bit

I'd be surprised if it is. Since most macs run 32bit mode by default (you can change that of course). iTunes, iWork are both 32bit. So is Warcraft. The good thing about Mac is that it doesn't really matter, since you can run either in either mode.

I was just curious.

 

[civ_king]

I'd be surprised if it is. Since most macs run 32bit mode by default (you can change that of course). iTunes, iWork are both 32bit. So is Warcraft. The good thing about Mac is that it doesn't really matter, since you can run either in either mode.

I was just curious.

iWork 09 is 32 bit because it worked on PPC 10.5 which had some G4s...
iTunes still works on PPC G4s therefore it is still 32 bit

The only reason Apple runs the computers still in 32 bit is because of drivers and most don't come with more than 4GB RAM which is where 64 bit starts gaining an edge on 32 bit

 

[jingo_man]

hi guys

hoping this will be a simple yes/no scenario...

mid-2007 iMac (with ATI Radeon HD2400 graphics card)

what possibility of playing Civ 5?

either "natively" (inside whatever java or other wrapper is used) or inside a virtual machine? if running as a vm, does vmware or parallels perform better? or even as a bootcamp windows o/s?

and of the above, which would provide best performance?

or, am i asking for something that just isnt going to happen? i bought the steam PC version, but that machine is primarily my HTPC, and i like to have background films on while playing Civ...

cheers (and hoping for good answers )

jingo_man

 

[dbratten]

Can anyone shed light on a concern I have with my purchase of a new iMac and it supporting Civ V?

I ask as my current 4-yr old iMac has a 7600GT card. After experiencing blacking out in later stages of the Civ IV game with big maps I was told by Aspyr tech support several years ago that Civ IV didn't work on that card although it was supposedly better than the sys requirements at the time. To work properly I needed the lessor card.

In all respects a new iMac should work well per the system requirements. But, will an i5 vs. an i7 make a difference. Or, a 5670 vs. a 5750 card? I plan to get the i7 and 5750 but could settle for less if it makes a difference.

Thanks for any insight.

 

[AlanH]

Hi, welcome

I don't expect anyone here can tell you whether a particular hardware config meets the requirements, other than to repeat the system requirements that Aspyr has published.

No one outside Aspyr has Civ5 for Mac yet (well, maybe a few beta testers, but they would be very foolish to break their NDA by even admitting their status).

 

[civ_king]

Can anyone shed light on a concern I have with my purchase of a new iMac and it supporting Civ V?

I ask as my current 4-yr old iMac has a 7600GT card. After experiencing blacking out in later stages of the Civ IV game with big maps I was told by Aspyr tech support several years ago that Civ IV didn't work on that card although it was supposedly better than the sys requirements at the time. To work properly I needed the lessor card.

In all respects a new iMac should work well per the system requirements. But, will an i5 vs. an i7 make a difference. Or, a 5670 vs. a 5750 card? I plan to get the i7 and 5750 but could settle for less if it makes a difference.

Thanks for any insight.

Definitely go with the i7, the 5750 is actually a Radeon Mobility 5870 (based off the desktop 5750)

 

[dbratten]

Thanks. I see it's out today and lists the 5750 card as supported. Guess I need to place my order.

 

[borad]

On first glance, it does appear to use multi-cores a bit more than the Windows version. On my early playing of a small map, it was typically using ~150% of a core on my Mac Pro 2008 (8 x 2.8Ghz). Earlier play in Boot Camp on the same machine used roughly 100% of a core, evenly split between two cores.

I'll have to try a huge map to see if it scales up.

Whether this is an actual indication of the port being coded better (GCD?) I haven't worked out yet -- and here's sympathy for those machines with less power to spare!

 

[civ_king]

On first glance, it does appear to use multi-cores a bit more than the Windows version. On my early playing of a small map, it was typically using ~150% of a core on my Mac Pro 2008 (8 x 2.8Ghz). Earlier play in Boot Camp on the same machine used roughly 100% of a core, evenly split between two cores.

I'll have to try a huge map to see if it scales up.

Whether this is an actual indication of the port being coded better (GCD?) I haven't worked out yet -- and here's sympathy for those machines with less power to spare!

It could very well be GCD since it is at such a basic level in the OS.

I really want to know the result of a game at maximum size with maximum Civs and City States hopefully it will be using four cores

 

[AlanH]

I really want to know the result of a game at maximum size with maximum Civs and City States hopefully it will be using four cores

Not on my 4 core 1st gen MacPro (nVidia 8800 GT).

I tried it. Huge map, 22 civs, pangeia. It peaked at 200% CPU during game setup, took a long time to start. I played the first turn, hit next turn and it crashed. There were ten threads operational in the crash log.

I tried again. Similar behaviour during setup. It didn't crash between turns, but used less than 100% IBT, and had 10 to 12 threads active.

You do have to create the threads in a particular way to exploit GCD. I suspect the multi-threading is built into the Firaxis code. If so it's unlikely it was re-optimised by Aspyr. I have been known to be wrong, though.

In any case, I doubt if the civs' decisions can be processed simultaneously between turns. How would you resolve attempts by two civs to contact or attack each other? Sounds like a recipe for disaster to me.

 

[civ_king]

Not on my 4 core 1st gen MacPro (nVidia 8800 GT).

I tried it. Huge map, 22 civs, pangeia. It peaked at 200% CPU during game setup, took a long time to start. I played the first turn, hit next turn and it crashed. There were ten threads operational in the crash log.

I tried again. Similar behaviour during setup. It didn't crash between turns, but used less than 100% IBT, and had 10 to 12 threads active.

You do have to create the threads in a particular way to exploit GCD. I suspect the multi-threading is built into the Firaxis code. If so it's unlikely it was re-optimised by Aspyr. I have been known to be wrong, though.

In any case, I doubt if the civs' decisions can be processed simultaneously between turns. How would you resolve attempts by two civs to contact or attack each other? Sounds like a recipe for disaster to me.

Darn
What does IBT mean?
Hopefully Aspyr will optimize the threading
You can't do multiple Civs at the same time, but since the AI thinks on four levels you could run those concurrently one civ at a time

 

[borad]

IBT = in between turns

I see 300% during map generation (which remains absurdly slow, and the lack of a re-generation function, as in Civ 4, doesn't help). I regularly see it top out at about 170% IBT. You can do some things massively in parallel (e.g. a worker could rate the effect of upgrading 50 different hexes entirely independently, then compare the result).

On that topic, it appears there is some severe inefficiency with worker calculations (on both platforms), which greatly affects the delay IBT, and improvements are listed for that in upcoming patches.

 

[civ_king]

IBT = in between turns

I see 300% during map generation (which remains absurdly slow, and the lack of a re-generation function, as in Civ 4, doesn't help). I regularly see it top out at about 170% IBT. You can do some things massively in parallel (e.g. a worker could rate the effect of upgrading 50 different hexes entirely independently, then compare the result).

On that topic, it appears there is some severe inefficiency with worker calculations (on both platforms), which greatly affects the delay IBT, and improvements are listed for that in upcoming patches.

Spoiler :

Loganalysis: What does the AI do in its turn?
While so far I assumed long AI turns on large maps where due to the AI plotting out incredibly intricate ( ) plans during its turn, I just decided to check out the logs of a single turn of one of my games to see what's going on.

Facts about the Match:
Map Type: Continents
Map Size: Large
Game Pace: Standard
Difficulty: King
Turn: 308
AI opponents still alive: 5/9 (2 Of them with huge areas)

Here's the result of what the AI opponents did and to how many weighing of options ('thoughts') this led:
- Considering whether or not to scout some of the cities close to them (or attack them)
---> All opponents together weighted ~2 actions for 66 cities, leading to ~132 'thoughts'

- Diplomatic considerations, including how dangerous other nations are, guessing their strength and how to continue with currently ongoing wars
--> Weak nations seemed to consider far less options than large ones (~1/3), but altogether it resulted in 512 'thoughts'

- Deciding how to handle their cities (economic decisions)
--> 84 'thoughts'

- Guessing what the other nations overall victory strategy was. They actually weren't all that bad at it (most guessing I'd go for cultural with diplomatic as second option. Diplomatic was my first choice, but aside from that...)
Fascinatingly enough there was also a guess from my nation about the others present
--> 210 'thoughts'

- Military decisions - what unit to move where and why (including flanking chances and stuff)
--> 349 'thoughts'

- What policies to take and what technology to go for next
--> 7 'thoughts'

- Where to move which worker next and why
--> 25889 'thoughts' (No Typo. > Twenty thousand thoughts.)


So yes... I'm beginning to get a slight feeling this might be the cause of slow-downs
I don't even wanna know how large this number can get on Huge maps

Of course, I realize that some weighing processes might take longer than others - but up to 7 factors where taken into account for every of those "which tile to work next 'thoughts'"
I mean, what the hell?
This is more than 20 times the amount of weighing processes than the rest of the AI considerations put together! O_O
Of course I didn't go through all the single lines but rather skimmed them, so maybe most of them are like real simple, but c'mon... 25889...

Turn Slowdown = AI Workers, some evidence
The largest sized map, almost entirely owned by the AI, could process turns in 1 to 2 seconds per turn with 175 fighter units and no workers. Changing these units to workers and no warriors causes turn times of up to one minute per turn. Read on for full research...

Following on from from the log analysis done by Dreamer here;
http://forums.2kgames.com/forums/showthread.php?t=94115
And my own comments, I recreated my 2 test scenarios to test with the latest patched version, and decided to actually record the turn timings and report them here.

What I did in the world-builder:
Created the largest possible map size scenario on a continents generated map-type, which generated two larged continents.
Using the world-builder, created 2 civs - a player civ with 1 starting city on one continent, and an AI civ with 35 starting cities each with a culture border expanding 2 hexes away from every city in all directions, dotted around the other continent. No cities have any buildings except for one capital for each player, which has a palace. Both players have these 4 techs only: Agriculture, Animal Husbandry, Mining, and Trapping (given so workers have a set of improvements they can work on). I set the AI civ to be in contact with, and at war with, the player civ. Both civs were given 50,000 starting gold.

Using this as the start scenario, I cloned this twice and with two identical copies, did the following:
* Gave the AI 5 warriors dotted around every city - 175 total warriors, no other units. (total unit maintenance cost = 0.5 gold per unit on turn 1)
* Gave the AI 5 workers dotted around every city - 175 total workers, no other units. (total unit maintenance cost = 0.5 gold per unit on turn 1)

Turn times for the "workerless" warrior-heavy scenario, from turns 1 through 20:
4, 2.2, 1.3, 2, 0.8, 1.4, 1.15, 1.89, 1.39, 1.69, 2.23, 1.59, 1.44, 1.58, 1.38, 1.78, 1.32, 1.38, 1.24, 1.5, etc. etc.
(I then started hitting enter without actually using the stopwatch, for possible another twenty turns, but every turn felt just as quick as the first timed 20).

Turn times for the "warriorless" worker-heavy scenario, from turns 1 through 20 (I've rounded these for simplicity sake):
21, 8, 7, 7, 6, 6, 6, 25, 22, 22, 22, 21, 23, 22, 22, 22, 22, 23, 23, 21, etc. etc.
(I continued to time turns for around another 15 turns or so, each one remaining at around 22 seconds).

These are identical maps - identical in every way except for one having 175 warriors for the AI (which it processes exceptionally quickly, even though it's in "war mode" against the player), and one having 175 workers for the AI.

I imagine that the block of 6 faster turns for the worker version were when every worker was busy - as initially at game start every worker got placed on a tile that could be improved, so I imagine that first turn was spent setting every worker to do jobs, then from turn 8 onwards each worker was requiring "re-processing", from which point each turn was around fifteen times slower. Also, roads were not researched initially - calculations for road locations also adds heavily to the slow-down, as do any other techs that allow workers to make improvements (hence later era games = much more slowdown, exponentially slower).

Keep in mind that this is with only one AI player, and 35 cities in control of the AI, and no city states at all. Only a small portion of the map was colonised (36 cities in grand total throughout the entire map) - most of you will encounter far more cities than that to be "developed" in a game, with many more culturally controlled tiles, which all adds to the processing.

Also keep in mind the "cultural borders" bug, which means that late game, when the AI has units all over the map and thus has much of the map in "line of sight", the worker processing increases exponentially, see this thread here for details on this bug;
http://forums.2kgames.com/forums/showthread.php?t=93309
In my tests, only a tiny portion of the map was in "line of sight", so the processing was much faster.

Note to any devs/employees: While these scenarios only took around 10 minutes for me to create, if that's 10 minutes too many, please PM me a contact email/drop-box location and I'd be happy to send you these two scenarios to test for yourselves.


TL;DR:
Turns processed at game start with 175 AI warriors and one AI civ take only 1.5 seconds on average.
Turns processed at game start with 175 AI workers and one AI civ take 22 seconds on average.
Tiles "in line of sight" exponentially increase processing time for these workers.
Number of cities on the map exponentially increase processing time for these workers.
Techs that allow improvements exponentially increase processing time for these workers.
AI workers are the major cause for all late game slowdown and turn processing, and can cause turns of several minutes late-game in huge games.

TL;DR:
Turns processed at game start with 175 AI warriors and one AI civ take only 1.5 seconds on average.
Turns processed at game start with 175 AI workers and one AI civ take 22 seconds on average.
Tiles "in line of sight" exponentially increase processing time for these workers.
Number of cities on the map exponentially increase processing time for these workers.
Techs that allow improvements exponentially increase processing time for these workers.
AI workers are the major cause for all late game slowdown and turn processing, and can cause turns of several minutes late-game in huge games.

yeah um...