Building a 0.76b1 compatible binary

[R1CH]

What's the secret? I'm trying to build my own binary so I have debug symbols and such, but whenever I join a game with other players, I get no response messages every 401 frames:

Code: Select all

Player R1CH joined as 4
GameID: 8d1ff4475ea9c86be68133e46da49f18
No response from R1CH for frame 1
No response from R1CH for frame 402
No response from R1CH for frame 803
No response from R1CH for frame 1204
User exited

I've tried changing optimizations and using source from SVN as well as the official 0.76b1 zip, but without any luck.

[Vadi]

I get sync error around every 400 frames also. Is there any info I can get to help out?

[aegis]

What happens every 400 frames?

[R1CH]

#define SYNCCHECK_MSG_TIMEOUT 400 // used to prevent msg spam

I guess I'm actually getting the error every frame then?

EDIT: It seems SYNCCHECK isn't defined for some reason, so no acks are sent. Maybe the debug build isn't synchronous or something. I guess I'll try the aptly-named Syncdebug :).

Syncdebug won't build, but defining SYNCCHECK stops the no response spam... but causes sync error after some minutes into game:

Code: Select all

Sync error for R1CH in frame 4517 (0x4E8661)
Sync error for R1CH in frame 4918 (0x34075F4C)
Sync error for R1CH in frame 5319 (0x37399472)

EDIT2: Building in release mode, same sync errors every time. I don't know what to do at this point.

[Kloot]

Which compiler? (Your Mantis entry suggests VS,
which won't sync with the official mingw builds.)

[zerver]

Along with these problems comes the advantage that it makes cheating a little harder :)

[Tobi]

Use GCC >= 4.0.0 as compiler.

[R1CH]

Why does compiler have an affect on sync? This would indicate that there is some platform / OS / compiler specific code in the synced portion which is bad, no?

[Tobi]

In short, because the synced code uses floating point math and compilers tend to perform optimizations on floating point code that subtly change the results of the calculations. (in particular when you enable stuff like --fast-math)

[R1CH]

Couldn't this be fixed by changing the FPU control word on all platforms so FPU operations are identical? I ran into similar FPU issues with Win32 vs Linux builds of the Q2 client and server and using --ffloat-store on the gcc builds syncs up with what MSVC was doing and finally adjusting the control words so they are identical on each platform provided perfect FPU sync. Maybe I'll play around with different FPU settings and see if I can find one that matches this GCC 4 build (I can only seem to find 3.x on MinGW, so I guess the official build is cross-compiled?)

EDIT: I see this is what strepflop is supposed to do. I guess maybe the gcc build has some FPU compile flags? I hope it isn't using -ffast-math!

[Tobi]

Control word is already set to 32 bit operation.

GCC build has some flags related to FPU operation, but only ones that are supposed to help solve sync.

Your observation is interesting though, I'll definitely see if I can check that sometime. (I don't recall explicitly testing just --float-store after the control word was fixed.) Did you use any special flags on the MSVC side? Which version of MSVC was this with anyway? Which control word did you use btw?

Btw, if you test, make sure to actually test something non-trivial. IIRC it only desyncs after a few minutes with MSVC, and even then it probably doesn't desync if you don't move units around etc. (I used to test GCC vs GCC using two bots playing against each other; GCC 3.X vs GCC 4.X in particular only desynced after ~8 minutes or so.)

[AF]

Fixed sync under Visual studio with gcc builds would give a 5-30% speed boost to the engine as well as making AI development much easier. Any attempt to improve compatability would be much appreciated.

[R1CH]

Is there a Makefile or something to build the gcc version? I'd like to see what cflags etc were used and try to replicate them under MSVC.

For Q2, the FPU was set to 24 bit precision, truncate to zero (chop) rounding. This lack of precision was unfortunately required to retain compatibility with existing binaries. I'm not sure if it's bit-for-bit perfect FPU sync since prediction misses between the client and server are ignored if there is <= 1 unit of slop, the client simply interpolates to match the server in any case. When the FPU was off it was definitely noticeable though.

I've been doing my testing in 4+ player games with real players who get into a state of panic and think I'm going to crash the game when they see me lose sync :).

[Vadi]

Yeah, been in one of those.

I'm not sure what's up with the losing sync & crashing - I spam with the not sync errors every 400 frames myself and the game seems okay. (Or, even if it's not the same game, I don't really care as it's still fun )

[Tobi]

Is there a Makefile or something to build the gcc version? I'd like to see what cflags etc were used and try to replicate them under MSVC.

We use scons.

The options are in rts/build/scons/rts.py, but it's a bit of a mess IMHO.

For Q2, the FPU was set to 24 bit precision, truncate to zero (chop) rounding. This lack of precision was unfortunately required to retain compatibility with existing binaries. I'm not sure if it's bit-for-bit perfect FPU sync since prediction misses between the client and server are ignored if there is <= 1 unit of slop, the client simply interpolates to match the server in any case. When the FPU was off it was definitely noticeable though.

24 bit? Was that SSE? IIRC X87 FPU can only be set to 32, 64 or 80 bit precision, though I may be wrong. EDIT: oh you mean just mantissa bits, not exponent... Then it's the same as Spring uses currently.

And unfortunately Spring can't even correct small mistakes so it has to be perfect sync...

[R1CH]

Ah forum is back now. I see the compile options for the gcc build use the following:

-fsingle-precision-constant', '-frounding-math', '-fsignaling-nans', '-mieee-fp

MSVC has no equivalent to the first, so I've gone through searching for truncation warnings from double to float and fixed those, but I'm sure there are more that simple warnings won't catch.

The second option I'm a little unclear as to what it does exactly, from the GCC docs its an experimental option to not produce code that depends on the rounding behaviour, but then what does it produce instead?

-fsignaling-nans seems somewhat redundant, not entirely sure of its purpose.

-mieee-fp is good I guess?

It's hard to find a MSVC equivalent for these. Perhaps the Intel C compiler would fare better.

[FLOZi]

Are you the TACC R1CH?

[LordMatt]

You weren't the dude that wrote conflict crusher (and other stuff) for OTA were you?

Yes I take full responsibility for that VB6 abomination :).

[FLOZi]

Cool beans.

[el_matarife]

Hey R1CH, would you mind updating your Spring maps site with all the newer maps? I think it still looks like 2006 over there.