terrain2 heightmaps smoothing calculation differs depending on optimization level

[anonymous]

It seems that depending on the optimizations done during compilation the heightmaps smoothing calculation gets different. The tests were done on the same planeshift revision on the same map (bdroad2) using always the same player mesh (klyrosm) (a good testing point is near point -293.70 23.76 383.89).

Three different clients were built with the different configurations for either crystalspace cal3d and planeshift.

A build done like this for cs and ps --enable-cpu-specific-optimizations=max CPPFLAGS=-march=native -mtune=native -msse3 -msse2 -msse -mmmx -mssse3 (and removing -march=i686 -mtune=generic from the ending jamconfig) and this for cal3d ./configure CPPFLAGS=-O3 -march=native -mtune=native -msse2 -msse3 -mssse3 -mmmx (-O2 was removed from all the generated makefiles)

ended up in a client were the player was continually stuck in the geometry.

Another test done with all the default settings ended up in a better situation. there were still micro stuck situations but it was still possible to move without staying stuck for up to 5 minutes like in the previous test

The last test was with a debug ps/cs/cal3d (with --enable-debug) there walking and running was extremely smooth and perfect.

[anonymous]

I forgot one thing all tests were done on linux (ubuntu intrepid) with gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2. Also it seems the builds done with release static on windows doesn't have the problem the used cs revision was r31648

[sxealex]

yes still happens on linux

[sxealex]

jorrit is possible that you explain how to change the cs compile settings here  http://www.hydlaa.com/flyspray_upgrade/index.php?do=details&task_id=2075 I am trying to fix this at least for myself atm XD

[anonymous]

after dumping the heigthmap calculated data i got differences at maximum of the order of 0,000xxx so this would exclude that(?). could the problem be in collision detection?