![]() |
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. |
All times are GMT -4. The time now is 12:42 AM. |
Powered by vBulletin® Version 3.8.1
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Copyright ©1999 - 2025, Shrapnel Games, Inc. - All Rights Reserved.