People seem to be treating the SSE requirement as a performance
consideration, but I think it's really about getting the same rounding
errors on all hosts:
From http://springrts.com/wiki/Build_from_source#Desync_in_game:
Spring only send the commands and not the result over the network, so
it needs to run all math in a repeatable manner, so all other clients
in a multiplayer match get the same results. So some CPU specific
features have to enabled/disabled. If you desync you either have a
CPU
that isn't SSE capable or you set the wrong -march /-mtune compiler
flags.
The i387 FPU (or whatever emulation of it actually exists in a modern
CPU) normally works in 80-bit precision internally and truncates to
32-
or 64-bit when writing into memory, whereas SSE always works in IEEE
32-bit/64-bit precision (for float/double respectively), as far as I
understand it?
So, SSE and non-SSE Spring executables, when fed the same data, can
potentially get different rounding errors and hence different results;
compound that over a whole game and you'll find you and your opponent
disagree about where your squad of robots/goblins/whatever have
ended up.
If this is the problem, then it might be sufficient to use gcc -
mpc64 or
gcc -mpc32, possibly with -mno-fused-madd, on i386... or not. (I am
not
a compiler ninja, those are just the options that info gcc said
affected
rounding.) To be honest, it might be best to have spring/i386 require
SSE and check for it on startup.
In theory this shouldn't be a problem for most of Debian's
architectures
because i386 is the unusual one here - I believe powerpc uses IEEE
32-bit floats and 64-bit doubles anyway - but I don't know whether
there
are other subtle differences. -mfpmath=sse is probably a good idea on
amd64 as well as i386.
(To be honest this sounds like a recipe for portability disaster to
me... I wonder how well i686, amd64, ppc Spring interoperate, and I
wonder whether upstream could be persuaded to use fixed-point (i.e.
integer) mathematics for network-relevant calculations in future
versions?)
Regards,
S
--
To UNSUBSCRIBE, email to debian-devel-games-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org