Incompatible battle replays across OSes

[Pocus]

and cant it be related to the rounding of some results, which would vary depending of the OS or the processor. Dunno how your algorithm works, but if it takes for example the 25th decimal of a number at a given time, like say

ln(0.123456789)
=
-2.091864070778393122967989 *7* 441961
on windows (being 7 there)
then perhaps it will be slightly different in linux.
?

[Johan K]

The random number generation itself should be foolproof. Only table lookups and some xor. Unfortunatelly the random number generation is only 0.0001% of what might go wrong, so your idea might still have some merit. The battles use sinus (sinf()) calculations and those might just be bad if those calculations should be significantly differnt on different machines. Definitely worth some thought...

[talos]

Originally posted by Johan K:
The battles use sinus (sinf()) calculations and those might just be bad if those calculations should be significantly differnt on different machines. Definitely worth some thought...

If you are using gcc, the trig functions should all be implemented to the IEEE standard, which is to say that they should produce the same results across platforms.

This is not true if you use other C compilers, or if you use -ffast-math with gcc, as this allows the compiler to use the hardware trig functions, which in may cases (intel for one) do _not_ quite meet the ieee spec. Of course --ffast-math speeds gcc up quite a bit, as it avoids software Versions of trig functions (maybe sqrt as well?).

Of course, such differences should be tiny, so they should only affect actual results with miniscule probability (like one in a few hundred thousand).

[Karacan]

For me (a windoze user), a game running on a linux server results in about approximately every eight to tenth battle being completely different in outcome - the others look vaguely correct (including the numbers of creatures fled into neighboring provinces, etc).

Annoying, but then again, it's time for me by now to stop watching every battle replay and just go for the numbers...

[PhilD]

Originally posted by Johan K:
The random number generation itself should be foolproof. Only table lookups and some xor. Unfortunatelly the random number generation is only 0.0001% of what might go wrong, so your idea might still have some merit. The battles use sinus (sinf()) calculations and those might just be bad if those calculations should be significantly differnt on different machines. Definitely worth some thought...

If you give me an email address, I'll send you my latest turn file, where under Linux, my Arcoscephale army gets eaten alive by Hoburg-backed Abysian Infantry, whereas under Windows, the very same Abysian Infantry routed pretty quickly (and the naked Hoburg Crossbows were no match for Arcoscephale's armies, even ineptly commanded by me).

There were a lot of things that could go wrong in this battle - some arrows and bolts, some trampling, some spells...

Also, bear in mind that any tiny different result, if it means "die rolls" are then scheduled differently, can mean the whole battle's outcome is different. One arrow landing in a different square, once, could mean one unit is now dead, or has a different number of hit points, or takes a morale check, so that the same dice rolls will be used for something different from now on. You cannot accept any variability in functions that are used during the battle replays.

[PrinzMegaherz]

I might add that I encountered this problem today in single player.

The review showed me a clear victory without any losses, the summary sais one of my commanders died.
And I'm very sure he is alive at the end of the replay

I'm using XP.

[alexti]

I've seen this problem many times in MP game I play now and I'd like you to consider the possibility that it's not just the replay being incompatible between the platforms.

In one battle I had won with only 2 mercs left (of some weak variety). Usually these mercs rout way before they all get killed, so I can't realy imagine a scenario in which it would it be possible to win with only 2 of them remaining (opposition consisted of some indy forces). Of course, in Dominions it's impossible to foresee everything and there may be some explanation I'm missing. Replay was showing my mercs retreating pretty quickly after losing few comrades. And I had few other battles with weird results. Everytime, development in the replay looks quite logical and probable, but battle report sometimes produce results which I couldn't interprete at all (meaning that I couldn't imagine how the battle would have to be going to produce such results - as in that example with 2 mercs left).

From my cross-platform programming experience I would have considered that maybe some variable is left uninitialized and on different OS/compilers it gets initiaized differently which produces consistently wrong results in the case of one OS (or different wrong results in different OS). This could explain strange results due to altered battle mechanics.