Menu
▾
▴
#7 Cross-platform multiplayer (i.e without 387 FPU requirement)
This is more of a feature request than a bug report.
I'd like to play 7kaa multiplayer using a Raspi, i.e. an architecture which does not have a 387 FPU.
My first attempt was to replace the -mfpmath=387 -ffloat-store in configure.ac by -fexcess-precision=standard, but I did get synchronization errors after playing for about 10 min.
I understand your issue, and really, you can't just do that. I can't support ARM right now, so unfortunately I can't address the request here.
Could you elaborate on "really, you can't just do that"? My naive assumption is that 7kaa does not depend on 387 floating-point semantics as such (after all singleplayer is fine on ARM), but just on the floating-point semantics being exactly the same on all machines in a multiplayer game.
So if all machines use the same semantics (no matter if 387, as now, or exact IEEE), multiplayer should work. Since exact IEEE is the semantics likely best supported across multiple architectures and toolchains, I'm aiming for that. I tried to think about it a bit further (though I haven't looked into the actual 7kaa code yet) and tried
-ffp-contract=off -fexcess-precision=standard -fno-fp-int-builtin-inexact, but still got a synchronization error after about 15 min of multiplayer gaming.Ok, so I know the code, and how it was written, and let's put multiplayer aside for a moment. The game was written for Intel x86, without any thought towards future expansion and portability. If it does work on ARM, it's because I have been practicing portable coding from the beginning when ever something was done. So that's good, at least we are heading in the right direction. But as the README states, we don't support ARM (and since there are several, which ones??). I have never tested it, and if I were to, I'd walk through everything that needs to work before testing multiplayer. So I can't say if your problem is some other issue, wrong fix, or incorrect way of testing it.
If I were to try to support ARM, a few more decisions would need to be made, but the possibility is there. Right now, there are still nagging issues that have existed due to moving to SDL2 on the platforms we do support. Which these SDL2 problems now will never be fixed if we stay on SDL2. The priority is moving to SDL3, which as the code improves on leveraging SDL3, this opens the door to more platforms. So if the port to SDL3 gets done, then I will consider which additional platforms can be supported.