ZDoom

Just to tell that the code changes could cause a division by zero on certain maps. Fixed that in https://github.com/rheit/zdoom/pull/169 .

I believe it's better if I move the code in a suitable function. Also, I found out that PIT_FindFloorCeiling has a similar code. Changing the new code with the PIT_FindFloorCeiling one, I get the desync, but I don't know if it happens also in 32 bit. Gotta check that.

[quote="GooberMan"]a 32-bit code build will use the full 80 bits of x87 precision internally before storing in the 32 bit float.[/quote]
This is true for GCC, but not VC++ (at least back when 2005 was state of the art). Actually, Direct3D 9 sets the FPU to use 32-bit registers, so ZDoom explicitly sets it to 64-bit registers.

[quote="edward850"]As it is currently, ZDoom in 64bit isn't actually any slower. At least when you can get the assembler to compile. There seems to be something wrong with fixrtext which makes it trip up when compiling x64 builds (likely as it wasn't designed with them in mind).[/quote]
Fixed the fixrtext issue and since I feel like causing trouble, I'm now building nightly 64-bit builds of ZDoom.

Side note for those who go benchmarking, there are two variables: VS2005 vs VS2013 and 32-bit vs 64-bit. I know on Linux the 64-bit builds are consistently slightly faster, but not anything worth really talking about.

I wouldn't expect anything to implement IEEE specs properly. I have noticed differences between Intel desktop processors and the Jaguar that powers the consoles (mostly with QNAN handling).

(Tiny edit: I've also had MSVC force 64-bit functions on 32-bit floats at times on x64 builds, which has caused problems as well.)

The 64 bit fixed point would make my 'SQWORD operands' idea applied to the inconsistency completely useless, until there's a way to declare a 128bit integer on all the systems. Or should we make a sort of 'arbitrary size integer' construct?

If the IEEE specs are properly implemented, results should be identical. When using x87 math its internal precision has to be set to 64 bit for that. The main problem with the floats is that the x87 doesn't handle floats properly according to spec and MSVC adds a significant amount of cruft to force all intermediate results into 32 bit, and I believe that was the cause for the discrepancy here.

[quote="Blzut3"]But maps would still need to be within the 32-bit fixed point coordinate system, which is significantly larger than what is currently permissible with 32-bit fixed point math.[/quote]
[quote="Graf Zahl"]Using 64 bit fixed point is only ok for isolated use as it produces some significant overhead with 32 bit code.[/quote]
The idea would be to increase it for 64bit builds, which may start to become viable as people (hopefully) start moving away from Windows XP, as 32bit processors are already very hard to find nowadays. Mind you, people continue to horde ancient GPUs, so who knows how long that will take.

As it is currently, ZDoom in 64bit isn't actually any slower. At least when you can get the assembler to compile. There seems to be something wrong with fixrtext which makes it trip up when compiling x64 builds (likely as it wasn't designed with them in mind).

[quote="Graf Zahl"]I'd rather see the engine ported to true double precision floating point with some extra care to the few places where underflows need to be considered (e.g. adding velocity or friction)[/quote]
Do doubles have the same problem as floats with different results per processor type and implementation? Or is that just with over/underflows, like with what was found with the slope code?

Using 64 bit fixed point is only ok for isolated use as it produces some significant overhead with 32 bit code.
I'd rather see the engine ported to true double precision floating point with some extra care to the few places where underflows need to be considered (e.g. adding velocity or friction)

[quote="edward850"]but DISABLE_SSE is defined[/quote]
It's possible this could use a better name, but the reason for this is to disable the run time detection of SSE. Since all x86-64 processors have SSE2, compilers default to optimizing for it and there's no reason to run time check for it. You'll notice that the SSE and non-SSE node builder functions are identical, it's just a difference in what compiler flags are used.
[quote="edward850"]Especially, if anybody wants to increase the available map size space anytime soon.[/quote]
Things like this really make me question what the point of increasing this limit would be. I believe it should be possible to fix those issues with a 64-bit fixed point type, much like what was done to fix this issue. But maps would still need to be within the 32-bit fixed point coordinate system, which is significantly larger than what is currently permissible with 32-bit fixed point math.

I did notice that ZDoom in 64bit is being compiled with SSE apparently switched off (I can't find any set compiler flag, which is interesting, but DISABLE_SSE is defined which affects the internal node builder). If it really does change the result of floats, I might need to do some testing with large explosions and the like, as that and vectors are another key place where floats are used.
None of it seems dramatically different to be actually making a difference, though. Although I haven't tested GZDoom yet between systems, which might need to be done if float precision was changed (which might manifest problems between CPUs alone).

Problem is, if any more problems arise, while explosions and other radius collection functions could be fixed by using long integer math, like slopes, I have no idea what could possibly be done with vectors. Especially, if anybody wants to increase the available map size space anytime soon.

It's likely they'd even manifest themselves between 32bit x87 and 32 bit SSE2 if it's really the float math. The CMake project allows setting both with the recent MSVC compilers.

I wonder how GZDoom fares, because I switched floating point consistency from precise to fast because the GL renderer depends on floating point efficiency.

Can't say forcing x87 is a good idea. As you stated it wouldn't help with ARM, MIPS, and PowerPC compatibility, which is something we should have. It's good that these minor differences can manifest themselves in 32 vs 64-bit x86 as these platforms are commonly available for debugging.

Most likely, but demo and multiplayer compatability is another matter entirely.

Am I remembering incorrectly, or did someone get ZDoom sort-of working on an ARM already?

There's likely plenty of these dotted about the engine. x64 compilers by default spit out SSE code, which gives different results to x87 code. Basically, those floats will only be calculated with 32 bits on 64-bit code builds, while a 32-bit code build will use the full 80 bits of x87 precision internally before storing in the 32 bit float. The double version on a 64-bit code build would calculate at 64 bit precision, hence the subtle differences.

It'll be a tricky one to completely handle going forward as more people use 64-bit code builds. It'll be very worthwhile investigating whether you can force your compiler to generate x87 instructions in 64 bit builds (I know at the very least that MS link will still link x87 instructions as I have a problem in completely and utterly independent code with 64-bit code generation using [url=http://dlang.org/]DMD[/url] going bonkers generating x87 code).

[b]EDIT:[/b] This, of course, implies compatibility on other platforms (such as ARM) is going to be nigh on impossible.