Dominions 3 on Dual Quad core machines

[Agrajag]

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.

I'm not really explaining this well, but I hope you understand anyway

EDIT: Just to be clear, I'm not saying "impossible!"*, I'm just saying "harder than you think."
*-obviously it is impossible, even if at the worst case scenario it would take rewriting the entire source code from scratch

[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.

[thejeff]

There are no simple non-deterministic pseudorandom generators.
In fact pseudo-random is pretty much equivalent to deterministic.

I believe Dominions does use a pseudo random generator not a pregenerated table.

The simplest implementation that comes to mind for doing the battles in parallel would be for each thread to work with it's own RNG and for the main process to generate the seeds for each battle before spinning off the thread.

[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.

[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.

[thejeff]

Battle resolution is independent in each phase.
Obviously fortress battles depend on the outcome of regular battles which depend on the outcome of ritual phase battles, but otherwise they don't affect each other.

The outcome of battles will affect where routed troops go, but that's handled after they are all resolved anyway. Troops routed from the first battle don't show up in a later battle in an adjacent province. They're spread out among any neighboring friendly provinces after all battles are resolved.

[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.

[thejeff]

I was about to concede on magic phase battles but argue that movement phase battles were independent, but then remembered the obvious counter: 2 different nations attacking the same province.

So, you're right. Battles are dependent on each other, spinning them off into parallel threads would be a major challenge.

[lch]

Not a major challenge, you'd just have to evaluate a graph, which battles could have any influence on others and then run the seperate battle simulator threads on the distinct connected sets. Still all this talk won't change that such a thing will never get implemented in any way, at all.

[JimMorrison]

Seriously, next to the rest of the programming, would it be that hard to simply have 2 tables to go off of? I mean, you just need to copy the first table (if they are pregenerated), and a miniscule amount of additional RAM/HD usage solves the entire problem. Now we just need the game to send some of the battles to core 2 and we're golden.


Damn, forgot there was a page 2..... Stop pissing in our cornflakes, Ich. <3