.com.unity Forums

.com.unity Forums (http://forum.shrapnelgames.com/index.php)
-   Dominions 3: The Awakening (http://forum.shrapnelgames.com/forumdisplay.php?f=138)
-   -   Dominions 3 on Dual Quad core machines (http://forum.shrapnelgames.com/showthread.php?t=38958)

weimaar May 26th, 2008 03:06 PM

Dominions 3 on Dual Quad core machines
 
Hi guys, i've noticed that Dominions 3 [peace be upon this game] only uses 1 single core when processing turns and creating the world. I usually play against impossible AIs with 15-20 nations which means that my maps are huge and it takes a while for the turns to be processed. Will there ever be a 64 bit version of the game or dual/quad core compatibility?

Endoperez May 26th, 2008 04:08 PM

Re: Dominions 3 on Dual Quad core machines
 
Doubtful, since any major changes to the core game are likely to cause huge problems. A recent example:

http://ulm.illwinter.com/dom3/dom3progress.html
Dominions 3 progress
17th may
* Version 3.17
* Major performance boost for windows version.

18th may
* Version 3.17 again
* Reverted performance boost for windows.

Loren May 26th, 2008 04:57 PM

Re: Dominions 3 on Dual Quad core machines
 
I seriously doubt they will do anything along these lines. I have no connection to Dominions but I am a programmer--and I know how hard it would be to revamp a mess of code (the code has previously been described as a major mess) to multi-thread execution.

MaxWilson May 26th, 2008 05:26 PM

Re: Dominions 3 on Dual Quad core machines
 
No chance. Dom3 is written in C, which is almost intrinsically sequential and thus single-core for the next few years. Take advantage of your dual core machine to play music in the background instead.

Making proper use of many-core machines is a problem the software industry is very much struggling with.

-Max

Agrajag May 26th, 2008 05:43 PM

Re: Dominions 3 on Dual Quad core machines
 
Play music? What a waste.
Just play two games simultaneously.
(unless it's a quadcore)

JimMorrison May 26th, 2008 05:58 PM

Re: Dominions 3 on Dual Quad core machines
 
Well they better hurry, Intel has promised to bring their 80 core processors to the consumer market within the next 4 years or so.

Loren May 26th, 2008 07:58 PM

Re: Dominions 3 on Dual Quad core machines
 
Quote:

MaxWilson said:
No chance. Dom3 is written in C, which is almost intrinsically sequential and thus single-core for the next few years. Take advantage of your dual core machine to play music in the background instead.

Making proper use of many-core machines is a problem the software industry is very much struggling with.

-Max

There's nothing about C that precludes doing things in separate threads. It's just an app not specifically designed for it generally takes a lot of work to convert.

There's also my opinion of C:

Programs, like ships, sink in the C.

Aezeal May 27th, 2008 04:09 AM

Re: Dominions 3 on Dual Quad core machines
 
That has got to be the very rare programmer humor. However rare it might be it's still not that funny though.

NTJedi May 27th, 2008 04:49 AM

Re: Dominions 3 on Dual Quad core machines
 
Quote:

MaxWilson said:
No chance. Dom3 is written in C, which is almost intrinsically sequential and thus single-core for the next few years. Take advantage of your dual core machine to play music in the background instead.

Making proper use of many-core machines is a problem the software industry is very much struggling with.

-Max

Well anyone playing multiple large SP games could run them both at the same time and use the 'set affinity' so each game can use different CPUs. Another idea is maybe running one MP game and one SP game using 'set affinity'.

Griefor May 27th, 2008 08:23 AM

Re: Dominions 3 on Dual Quad core machines
 
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.

Agrajag May 27th, 2008 09:23 AM

Re: Dominions 3 on Dual Quad core machines
 
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 http://forum.shrapnelgames.com/image...ies/tongue.gif

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 http://forum.shrapnelgames.com/image...ies/tongue.gif

Griefor May 27th, 2008 12:23 PM

Re: Dominions 3 on Dual Quad core machines
 
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 May 27th, 2008 12:43 PM

Re: Dominions 3 on Dual Quad core machines
 
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 May 27th, 2008 01:53 PM

Re: Dominions 3 on Dual Quad core machines
 
Quote:

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 May 27th, 2008 01:55 PM

Re: Dominions 3 on Dual Quad core machines
 
Quote:

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 May 27th, 2008 02:05 PM

Re: Dominions 3 on Dual Quad core machines
 
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 May 27th, 2008 02:38 PM

Re: Dominions 3 on Dual Quad core machines
 
Quote:

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 May 27th, 2008 02:48 PM

Re: Dominions 3 on Dual Quad core machines
 
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 May 27th, 2008 03:12 PM

Re: Dominions 3 on Dual Quad core machines
 
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. http://forum.shrapnelgames.com/images/smilies/laugh.gif

JimMorrison May 27th, 2008 03:20 PM

Re: Dominions 3 on Dual Quad core machines
 
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


thejeff May 27th, 2008 04:11 PM

Re: Dominions 3 on Dual Quad core machines
 
The magic phase battles could be hard to handle. Am I right in thinking that assassination spells (and assassinations?) occur along with the normal ritual casting and thus can interrupt, but that Teleport(etc) battles occur after all rituals have been cast? You can't interrupt someone's casting by teleporting onto his lab?

If so, it's not too much harder. Deal with all the assassinations. Spawn a thread for each province's magic phase battles.
Deal with the results and army movement, etc.
Spawn a thread for each province's movement phase battles.
Deal with the results
Spawn a thread for each fortress battle.

It's not even a graph. I think for each phase it's confined to a province. You'd need to resolve everything in a phase before moving on to the next anyway.

Aezeal May 27th, 2008 04:18 PM

Re: Dominions 3 on Dual Quad core machines
 
just PM the programmer himself and ask if he can do it.. it's known the makers don't like others messing in there code so if he can't it won't be done.. if he can there might still be a zillion reasons why he won't do it (busy with other stuff outside dominions being nr 1 I'd figure and if busy with dominions then probably fixing bugs takes priority) .. but you could ask..

JimMorrison May 27th, 2008 05:40 PM

Re: Dominions 3 on Dual Quad core machines
 
Well this discussion is somewhat important (if the facts can be gotten straight). In my experience, programmers tend to HATE being asked to change code unless you actually know what you want. If you just say "hey, can I get fries with that", your response tends to be, "sorry, there are no fries, but I can give you extra ketchup". Now, if you say "if I turn on the fryer and add fresh oil, can we have fries?", sometimes you get a favorable reaction. Of course, sometimes the response is "those fries are frozen, if you put them in hot oil it will practically explode giving us all third degree burns, are you an idiot???". That is when you give thanks that we even have a Dominions 3, single core or otherwise. http://forum.shrapnelgames.com/images/smilies/wink.gif

Taqwus May 27th, 2008 05:56 PM

Unlikely.
 
1- Concurrency control is not something that should be grafted on after, if the code was not designed with it in mind.

There's much more to it than 'could this battle affect the outcome of another', for instance -- or how one seeds PRNG tables. There's also quite likely to be shared data structures (notably, the table of units -- and units get both created and destroyed in battle), for instance. There may be static variables that would need to become thread-local. And so forth.

Grafting on MT-ness is a serious pain. That's true even in languages which are designed for it, unlike ANSI C. It's even more true if you're using libraries, because you can't really assume that the people who coded the libraries made -their- code MT safe, or if they've provided sufficiently fine-grained locking to enable the serialization you need. Yeah, individual operations may be atomic... but if they didn't give you the methods to lock a sequence?

2- Dominions is unusually quite cross-platform. ANSI C does not specify any threading infrastructure, let alone a cross-platform one. Pthreads *might* serve, but the last release on Windows seems to be from 2006, so it wouldn't surprise me too much if it broke on more recent OSes.

Writing MT code for even one OS is enough of a pain.

Griefor May 27th, 2008 06:48 PM

Re: Unlikely.
 
That's something that would have to be figured out. I have no idea how Dominions 3 saves its data, but if it is done somewhat modularly it shouldn't be a huge problem. Table of units? Is there one huge array holding all the units? Or are they saved per-province? I really can't see myself programming something like Dominions 3 and then writing it in such a way that deleting a unit from province A would somehow affect (move or alter) the data detailing a unit from province B. And that is just simple single-thread writing.

Unix/Linux/Windows thread code is different but it's not very hard to write an OS dependent function that works the same for each of these. Cross-platform writing in c is a huge chore, but if the devs wrote the current cross-platform version they are very capable of writing cross-platform c code. I see multithread being a cross-platform problem, but not moreso than networking, graphics, or a handful of other stuff that's already in the game.

I still have to agree with Ich though: this will never, ever be implemented. But I find it fun to discuss it, for some reason.

Aezeal May 27th, 2008 08:46 PM

Re: Unlikely.
 
hmm well I'm no programmer but still I think it's very hard to tell what JK would need or want to hear from you, so asking him would just be shorter http://forum.shrapnelgames.com/images/smilies/laugh.gif

NTJedi May 28th, 2008 12:36 AM

Re: Unlikely.
 


Ideally I think Illwinter should seek multiple ways of improving game performance.

Even more important would be including some advanced game options allowing more powerful computers to have larger limits. As computers become more and more powerful it would be great if gamers could decide:
1) how many battle turns are permitted
2) settings for maximum commanders and units during a game
3) {{ I'm sure there's more }}

Twan May 28th, 2008 08:04 AM

Re: Unlikely.
 
Personnally, I think playing a turn is so long in late game, that resolution length has no importance.

I mean, seriously, you just spent one hour giving orders... do you really have nothing else to do than waiting in front of your computer during the 3 or 4 minutes hosting takes (... and before spending ten minutes watching the replays and another hour giving orders for the next turn) ?

Zeldor May 28th, 2008 10:08 AM

Re: Unlikely.
 
IT is like 30 minutes hosting if you do 1 hour turn against AI http://forum.shrapnelgames.com/images/smilies/happy.gif

NTJedi May 28th, 2008 12:23 PM

Re: Unlikely.
 
Quote:

Twan said:
Personnally, I think playing a turn is so long in late game, that resolution length has no importance.

Battle turn resolution length is very important for large major battles during late game. I've lost large mindless armies and SC's because the battle turn length could not continue for an extra 10 rounds.


Quote:

Twan said:
I mean, seriously, you just spent one hour giving orders... do you really have nothing else to do than waiting in front of your computer during the 3 or 4 minutes hosting takes (... and before spending ten minutes watching the replays and another hour giving orders for the next turn) ?

Waiting in front of the computer?? Anyone playing large maps knows you don't wait for the turn hosting during late game. As mentioned by Zeldor it's about 30mins for one hour of work, my faster systems cut the time almost in half. Typically I'll do housework, work research, eat some snacks then head back to start the next turn.
Honestly I wouldn't mind if processing a turn took longer as battles didn't have attacking units retreating after 50_turns. Each gamer should have the option of deciding the duration of battle turns and unit/commander limits.

thejeff May 28th, 2008 12:39 PM

Re: Unlikely.
 
I think that's what Twan was talking about with "resolution length", not how many rounds, but actual time to process.

I had only battle that took several hours to display, not that I watched the whole thing, just let it run while I did other things, but I wanted to see what he had left at the end.

It would have ended eventually, both sides were still taking casualties, but I shudder to think how long it would have lasted.

NTJedi May 28th, 2008 12:50 PM

Re: Unlikely.
 
Quote:

thejeff said:
I think that's what Twan was talking about with "resolution length", not how many rounds, but actual time to process.

I had only battle that took several hours to display, not that I watched the whole thing, just let it run while I did other things, but I wanted to see what he had left at the end.

It would have ended eventually, both sides were still taking casualties, but I shudder to think how long it would have lasted.

Well I wouldn't mind watching an important large battle which lasted 102_turns. Watching many battles is the phase I call... dinner and a movie. While watching many battles for a large map is when I'll eat my dinner or perhaps lunch. Ideally each gamer should be able to decide the length of battles.


All times are GMT -4. The time now is 06:33 PM.

Powered by vBulletin® Version 3.8.1
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Copyright ©1999 - 2025, Shrapnel Games, Inc. - All Rights Reserved.