Observer Is Aspyr Media's Latest Linux Game Release, No Radeon GPU Support

[F.Ultra]

Getting cross-platform consistent floating point results is not trivial but straightforward. Plus MSVC can create Linux executables nowadays.
Likely getting cross-platform multiplayer requires making changes to the Windows codebase, but this all boils down to whether the involved companies want to. Not any technical hurdles preventing this.

Wow, what a shitty answer from Aspyr. The way I read it, they did not have any plans from the beginning.

To get cross-platform consistent floating point results you basically have to do software emulation of all IEEE calculations (goodbye performance). We are not talking about the resulting floating point values but the raw 64-bit binary value of a double which is a problem that affects no one else (which is why there is no one at GCC or MSVC that even thinks about making this work cross-platform) but the stupid fucks who made this engine that basis everything on the raw binary values and not the resulting floating point value.

If I'm not too mistaken the main issue here is that GCC extends IEEE calculations to long doubles (i.e 128-bit floats) and then converts it to 64-bit floats when it sees fit to store the actual result in memory (which can be non-deterministic due to optimizations) while MSVC does everything with 64-bit floats.

To use MSVC to build a Linux version of the code might help, but I don't know if this is a viable route for Feral, Aspyr and the other porters.

[Hi-Angel]

I'm quite sure Feral have done so but I don't think that they care, Windows is their main selling platform and if they changed their code with say compile everything with GCC as some here talked about then they would break Windows multiplayer for people who do not upgrade to latest version so I don't think that they will do that either.

Well, granted I know nothing of that engine and protocol, but I imagine there are some workarounds, like a change in serialization to be compatible with any compiler, and may be using protocol versions along with old codepath to not break old clients.

UPD: ok, I think the comment higher (beaten me in dozens of seconds :Ь) pretty much answers it.

[chithanh]

To get cross-platform consistent floating point results you basically have to do software emulation of all IEEE calculations (goodbye performance).

No, going to that length is not necessary. Several open source game engines achieve consistent floating point by means of a helper library, streflop, which provides wrappers to known good implementations of IEEE 754. Even where that is not an option, it is possible to ensure through certain coding practices that compilers try not to "optimize" your code into something that gives different results (avoiding contractions like FMA or algebraic optimizations).

the stupid fucks who made this engine that basis everything on the raw binary values and not the resulting floating point value.

If I'm not too mistaken the main issue here is that GCC extends IEEE calculations to long doubles (i.e 128-bit floats) and then converts it to 64-bit floats when it sees fit to store the actual result in memory (which can be non-deterministic due to optimizations) while MSVC does everything with 64-bit floats.

I think you are mistaken. If the raw binary value differs, then also the resulting floating point value differs.

The problem of higher precision intermediate results is historically mainly the x87 FPU which uses 80-bit registers. It is however possible to configure the FP CSR to 64-bit or 32-bit intermediate representation. This stopped being a problem since SSE2, which provides IEEE 754 compliant floating point math.

The next problem (as I mentioned above) is that compilers sometimes apply algebraic transformations to code when they shouldn't, e.g. optimizing the statement x*(y+1) to x*y+x which gives slightly different results.

If you want to know more, I suggest that you start reading here:

https://springrts.com/phpbb/viewtopic.php?t=33030

http://yosefk.com/blog/consistency-how-to-defeat-the-purpose-of-ieee-floating-point.html

[Hi-Angel]

Thanks chithanh, ⁺¹ for the articles!

What we're saying is the exact opposite of "IEEE FP sucks". It's "IEEE FP is so damn precise and fast that I'm happy with ALL of its many answers – the one in optimized x86 build, the one in debug PowerPC build, the one before I added a couple of local variables to that function and the one I got after that change.

Quote of the day

[smitty3268]

No, going to that length is not necessary. Several open source game engines achieve consistent floating point by means of a helper library, streflop, which provides wrappers to known good implementations of IEEE 754. Even where that is not an option, it is possible to ensure through certain coding practices that compilers try not to "optimize" your code into something that gives different results (avoiding contractions like FMA or algebraic optimizations).

Right, but that would require editing the Windows game binaries and pushing out an update to all the windows gamers. Aspyr and Feral don't have the rights to do that, and there's no way the game owners are going to give it to them because they don't want to have to go through the hassle on their end of updating 99% of their game's userbase which already has a tested and working version to fix it for the other newly added 1%.

If they were going to do that kind of work it would be done in-house anyway, rather than just throwing the code to these external porters and letting them try to make something from it on linux and mac.

[F.Ultra]

I think you are mistaken. If the raw binary value differs, then also the resulting floating point value differs.

No, as long as you follow the rounding rules if IEEE values (i.e 7 significant digits for floats and 15 for doubles) you can have small differences that doesn't effect the generated float. This is i.e why you cannot do "if (value1 == value2)" if both are floats/doubles since the comparison is done on the binary level so this could/would fail even if both semantically represent the same value.

Regarding the rest of your post and streflop, it might be the solution. I don't know since I have no part in this, I just posted what the devs from Feral have written on why they could not make multiplayer work with that engine (don't remember which engine it is though but it seams to be widely used in games).

[frosth]

I don't know what happend here, there is mesa 17.2.x with good opengl/vulkan support. I cannot find any playtrough or good answer if it works on mesa. I've just finished DeusMD and looking for something new so instead of spend ~23€ for observer_ i've just bought DEX.

[chithanh]

Right, but that would require editing the Windows game binaries and pushing out an update to all the windows gamers. Aspyr and Feral don't have the rights to do that, and there's no way the game owners are going to give it to them because they don't want to have to go through the hassle on their end of updating 99% of their game's userbase which already has a tested and working version to fix it for the other newly added 1%.

This is why I said "the involved companies". If the developer is not interested in supporting cross-platform multiplayer, then that is known already when the porting contract is made.

No, as long as you follow the rounding rules if IEEE values (i.e 7 significant digits for floats and 15 for doubles) you can have small differences that doesn't effect the generated float. This is i.e why you cannot do "if (value1 == value2)" if both are floats/doubles since the comparison is done on the binary level so this could/would fail even if both semantically represent the same value.

As I wrote, this is only true at the register level, e.g. in x87 FPU which uses 80 bits intermediate representation for 32 or 64 bit floats by default. This is not true for SSE2 which provides IEEE 754 compliant FP operations.

Regarding the rest of your post and streflop, it might be the solution. I don't know since I have no part in this, I just posted what the devs from Feral have written on why they could not make multiplayer work with that engine (don't remember which engine it is though but it seams to be widely used in games).

Can you link to the source of that statement?

[F.Ultra]

This is why I said "the involved companies". If the developer is not interested in supporting cross-platform multiplayer, then that is known already when the porting contract is made.

As I wrote, this is only true at the register level, e.g. in x87 FPU which uses 80 bits intermediate representation for 32 or 64 bit floats by default. This is not true for SSE2 which provides IEEE 754 compliant FP operations.

Can you link to the source of that statement?

Feral have an active account on https://www.gamingonlinux.com/ where they used it to comment on the missing cross-platform multiplayer for some of their ports, but I don't remember for which game it was and their search didn't turn up anything. Sorry.