Dominions 3 on Dual Quad core machines

[Griefor]

Actually, random numbers are a good point. I hadn't considered those.

Unless the reverse engineering I did in my mind is wrong, Dominions relies on the deterministic nature of its code to produce the same battle results on every machine a game is played on. Without prerandomized numbers, a random number generator (one of those pseudorandom generators which produces the same results if you seed it with a static value) would still suffer from the same problem - it's only deterministic if all the calls to it occur in the same order every time.

As you said I'm sure it's still a solvable problem, but it's definitely something that would have to be thought about.

I *still* think it wouldn't be incredibly difficult to implement this, but I also don't think it's really necessary enough to warrant the work anyway. In my big SP game experience loading times were really not all that horrible. Although if it's just for SP, a simple pseudorandom generator that isn't deterministic would probably be sufficient anyway.

[Loren]

Agrajag said:
I'm pretty sure it won't work.
IIRC Dominions uses tables of prerandomized numbers, and to show a battle again just means starting at the right place in the right table and recalculating the whole thing all over again.
If you simulate more than one battle at once, you can't tell which random numbers belong to which battle, since they'll all be taking random numbers randomly.

Non-issue--the generator simply needs to pull it's seed from thread data instead of global data.

[Loren]

Griefor said:
While converting the entire application to multicore might be a huge amount of work, I'd think that converting just the battle resolution (which is the only thing that takes a lot of time anyway) shouldn't be that hard. As long as you know what you're doing (this is probably not a good first attempt at multicore usage) and the battle resolution is programmed the right way in the current state.

I mean, think about it. Every turn there is a bunch of battles, and they're all mostly independent from each other. The flow of the program might have to be changed somewhat ( prepare all battles first, then resolve them all), but the subsequent multitasking is basically just resolving multiple battles at the same time rather than one at a time.

Nope. Battle resolution isn't independent when there are battles next to each other.

[MaxWilson]

Loren said:
Nope. Battle resolution isn't independent when there are battles next to each other.

Yes. I've occasionally had units do a HALO drop (via Cloud Trapeze) into one province for a strike on an attacking army, then run away and wind up in the province the army attacks. Thus, taking part in two battles on a turn. You also have to consider assassinations and fortress assaults. Within the magic phase, a unit could suffer an assassination spell attack and then fight off a teleporting attacker, and if it survives could teleport elsewhere to attack someone itself.

Battles are not independent, and figuring out the dependencies would be nontrivial.

-Max

Edit: typo fix.