![]() |
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?
|
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. |
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.
|
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 |
Re: Dominions 3 on Dual Quad core machines
Play music? What a waste.
Just play two games simultaneously. (unless it's a quadcore) |
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.
|
Re: Dominions 3 on Dual Quad core machines
Quote:
There's also my opinion of C: Programs, like ships, sink in the C. |
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.
|
Re: Dominions 3 on Dual Quad core machines
Quote:
|
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. |
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 |
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. |
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. |
Re: Dominions 3 on Dual Quad core machines
Quote:
|
Re: Dominions 3 on Dual Quad core machines
Quote:
|
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. |
Re: Dominions 3 on Dual Quad core machines
Quote:
Battles are not independent, and figuring out the dependencies would be nontrivial. -Max Edit: typo fix. |
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. |
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
|
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 |
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. |
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..
|
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
|
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. |
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. |
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
|
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 }} |
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) ? |
Re: Unlikely.
IT is like 30 minutes hosting if you do 1 hour turn against AI http://forum.shrapnelgames.com/images/smilies/happy.gif
|
Re: Unlikely.
Quote:
Quote:
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. |
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. |
Re: Unlikely.
Quote:
|
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.