Incompatible battle replays across OSes

[Johan K]

The OS inconsistency is not related to the random number generator (hopefully) as Dominions uses its own random number algorithm. But something sure seems to be weird.

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