Question about Haxe, Nape and deterministic compilation

So I first asked this question on the nape forum to no answer so far.
But since this question is larger than just the physic engine, maybe some of you know a bit of the answer.

So I’m making an online multiplayer fighting game, physics are based on Nape (Haxe).
I figured how to make 2 games sync with deterministic lockstep locally. (Nape is already deterministic on the same computer, but I had to change Movieclip frame based)
It’s functionning and I have no desync between two games sending UPD packets, but again, that’s on the same computer.

Now I know it’s not going to work across different machines, but my question is, what would it take to make Nape and Haxe? deterministic between most machines, architecture ?

I’ve heard the problem is about floating points interpretation.
But in this article, developers achieved such a thing with their own engine and they seem to say the problem is not about floating points, could be compilation setup.

Is there a way to add compilation arguments to make sure it compile with internal precision set to 64 bits and “strict” IEEE 754 compliant mode ?

Here are a few things been said :

During development, we discovered that AMD and Intel processors produced slightly different results for trancendental functions (sin, cos, tan, and their inverses), so we had to wrap them in non-optimized function calls to force the compiler to leave them at single-precision

As long as you stick to a single compiler, and a single CPU instruction set, it is possible to make floating point fully deterministic. The specifics vary by platform (i e, different between x86, x64 and PPC). You have to make sure that the internal precision is set to 64 bits (not 80, because only Intel implements that), and that the rounding mode is consistent.

We did however have problems when using some physics APIs because their code did not have determinism or reproducibility in mind. For example some physics APIS have solvers that take X number of iterations when solving where X can be lower with faster CPUs.

I don’t think Nape has iterations based on cpu speed, that’s up to the “deltaTime, velocityIterations, positionIterations” l right ?

So if someone can help me go to the right direction, I would be grateful.
Thanks for your help.

Go to (location of your HXCPP install)/toolchain and look for the MSVC, Mac or Linux toolchain XML, that is the file used when compiling to C++, and should provide a starting point for customizing compilation

I wonder if HL (HashLink) would help in this regard, since it is a fast VM rather than compiled code

Ok thank you !
I think I found the flag to have 64bits internal precision on mac and linux MSVC xml
<flag value="-m64" if="HXCPP_M64"/>
What about this :


Could it help to use LITTLE_ENDIAN instead of BIG or memory endian has nothing to do with floating point consistency… I’m confused.

Might be silly but why windows doesn’t have an MSVC xml as well ?

How about “strict” IEEE 754 compliant mode, is there a way to customize this as well ?

They should default to LITTLE_ENDIAN

“mac-toolchain.xml”, “linux-toolchain.xml” and “msvc-toolchain.xml” should be the standard HXCPP toolchain configuration for Mac OS, Linux and WINDOWS respectively :smile:

I don’t personally know about IEEE 754 compliance, but those files should allow you to play with adding new defines to your builds, so you can research and try any MSVC, GCC or clang build flags

Thank You Joshua !
I found out what I’m looking for is probably this

<flag value = "/fp:precise" if="MSVC17+" />

for windows and maybe -DHXCPP_FLOAT64 in the toolchain/common-defines.xml for linux and mac.

I’m really interested to try HashLink VM, I just can’t figure out how to compile, it says to use haxe compiler :
haxe -hl output.hl -main MyApp (MyApp being the main starting class)
I get an obvious Type not found on my main class…
How could the compiler knows included libraries defined in project.xml without giving a link to it ?
I must be missing something here.

1 Like

Hashlink won’t help you as the JIT is 32 bit only and if you compile your code for 64 bit you won’t be able to run it on the VM

Lime CFFI needs to be updated to work with HL, once we sort that out, HL support would be possible, I believe, and be exciting :slight_smile:

1 Like

I saw that the Heaps repo already has some old Lime support in there… it might be worth updating that to work with the current Lime. So far I’ve been using the 32bit HL binary and libraries to run it within its VM, but it would be interesting to have that same code compile against Lime for distribution purposes.

I made some fixes here, but it gets a black screen at runtime:

It’s not perfect, but should be a start for anyone interested in digging further :slight_smile:

Nice one Joshua!
I’ll have a look at this too asap and see if I can figure out why it’s showing a black screen. It would be nice to use lime to make heaps run on mobile

@singmajesty my journey has already stopped. I’m having issues with hxcpp trying to get heaps to compile. It’s actually a line in the png tools of the format library that’s giving me issues: