NON-cross-platform Burst determinism?

First of all: this post is only about windows computers and the same version of the game.

Hello,

Since the cross-platform (cross-architectural) determinism of Burst is being delayed, and my project was about the fact that determinism is coming soon, I would like to clarify about the current determinism of Burst code.

When I was looking for information about float in C#, I often saw messages that desynchronization can be caused by the CPU architecture, OS version, installed drivers, etc. However, as far as I understood from the answer on this forum, Burst only requires the same CPU architecture for determinism. This is true?

According to Steam, most players use Intel processors (~ 70%). As far as I understand, almost all of these processors are x64 (not x86) now.

Do I understand correctly that at the moment Burst guarantees me determinism for almost all modern Intel processors (i3, i5, i7, i9) for its code (including DOTS Physics)? Regardless of the OS version, drivers, video card, etc. Of course, provided that I myself do not violate the principles of determinism in my code. Or are there still conditions necessary for determinism?

Also, I would just like to clarify: do I understand correctly that all or almost all (except x86, if any) modern (i3, i5, i7, i9) Intel processors are considered processors with the same architecture?

I'm prepared for the fact that some players won't be able to play with each other (multiplayer via lockstep) if most players can.

I have already received an answer to a similar question, but since in a few months I am going to prepare the game for release, and the release date of cross-platform determinism is unknown, I am asking a little more specifically to get a definite answer.

I also wanted to clarify about determinism for the following sections (about NON-crossarchitectural determinism):
NavMeshQuery (burst) deterministic?
NavMeshObstacne / NavMeshLink are deterministic (if I create obstacles in identical positions on two clients, will the mesh (and pathfinding) be identical)?
NavMeshBuilder (runtime version) is deterministic?
Mono or IL2CPP don't matter?

And is ANY math in Unity (not Burst) deterministic on the same CPU architecture (again, unless my code uses random paramters, deltaTime, etc.)?

Thanks.

 

I made a project in the hope of a speedy determinism based on these messages from Joachim_Ante:

apparently I misunderstood them.

That is, at the moment it is impossible to obtain even a partial "determinism for the majority of players on the same platform" using existing solutions?

About six months ago, I tested lockstep multiplayer on two devices: intel core i7 (windows 10) vs intel core i5 (windows 7). In the game, hundreds of units simply walked and pushed each other (steering). I only used my code (and Unity's math) in Burst. After 10 minutes, there was no desync checks.
Do I understand correctly that it was "just luck with similar processors"? And that at the moment one cannot count on the fact that most people will be able to have determinism?

And the only solution is to wait for the cross-platform Burst, which is postponed indefinitely?

 

I am in a similar boat. Joachim Ante, and it goes back awhile, I understood him as being adamant that burst was determinism on the desktop platform.

If that is not the case and insuring determinism is impossible. I am not so far along that going back to a brute force client server would be impossible.

I hope if DOTS ever gets a roadmap that this will be addressed. If DOTS determinism had a time schedule I would consider continuing DOTS development. But it looks like I may have to do a 180 and switch gears. I only have a month or so into full time DOTS dev and was just getting to the point where I thought I was in a good position.

I don't blame Joachim Ante, determinism is complex, but I cannot develop in the blind and cannot control Unity's part of the equation.

 

I'm guessing the dynamic CPU feature dispatch on desktop is a factor here. So a CPU with AVX and a CPU without may behave differently.

 

Yes determinism sounded too good to be true. Given SIMD and that Burst also optimizes for that. Kind of the opposite of what you want for determinism.

 

However, this worked in my tests. Apparently I was just "lucky", because I could only test on two different devices.

 

That is the problem with testing for determinism. Luck is a massive factor.

 

As said above, there's some conflicting information about this coming from Unity. Not just from Joachim noted above, but there are other forum posts claim determinism across same architecture. For example, Unity Physics apparently even has test coverage for determinism: https://forum.unity.com/threads/wha...rminism-of-unity-physics.922055/#post-6040217

I also remember reading posts claiming burst being currently deterministic across same build (architecture + platform), i.e. windows-x64 should be deterministic even across intel/amd, as long as it's same platform.

It'd be nice to have some clarification on this.

 

In fact, I am prepared for the fact that 49% of players will not be able to play with each other if 51% can successfully use multiplayer. I am using math (Unity.Mathematics), Unity.Physics and NavMeshQuery. I use different math functions: transformation matrices, square root, etc.

For the last six months I have been working on a project in the hope of a cross-platform determinism release. However, the game is getting closer to the alpha version, but determinism is postponed.

Therefore, I need to know: can I sacrifice a minority of players, and be sure that the majority can successfully have determinism and play online, or should I freeze the project for a long period (before the release of cross-platform determinism)? I am ready to lose half of my audience (especially if I can immediately put the requirement "only for Intel" or the like), but if it is ABSOLUTELY accidental, I will have to freeze my project, but not receive completely negative feedback from the players. Can I be sure that for players with a certain list of processors (or the like), determinism will work in most cases?

UPD:
Is it possible to somehow indicate to the player that he should change something?
How many variations of these instructions are there? I mean: will I get 5 or 10 groups of players who can only play in their own group without problems, or can there be an infinite number of such groups? If there are not many of them, I could, for example, carry out a simulation in several frames and give the players hashes so that they know the possibility of playing with each other until the moment of purchase. But it only makes sense if there are very few such groups.

 

Real question is, what cases really require determinism and which - do not?
Perhaps error correction can be applied for the cases that cause server / client desync, resolving this issue until cross-platform determinism arrives.

 

If you add correction you will eliminate the advantages of having determinism and add lag. The whole point is that you can rely on input returning the same output everywhere. Firing a bullet for example could cause massive complex changes to the sim.

Desync correction if it happens rarely maybe ok. But going blind it is more likely that some players desync always.

 

Unfortunately this is not possible. Up to 10 thousand units participate in my game. Moreover, many of them are not typical (spells, etc.). Therefore, it is almost impossible to synchronize such a number of units, projectiles, spells over the network.
According to my approximate calculations, at least 1MB is spent on 1 synchronization of the world. I understand that in theory this can be optimized (synchronize in parts, rarely, only "hazardous" areas, etc.), but I wanted to use steam p2p, and as far as I know, the traffic there is very limited. And using another server with such a large volume of traffic is too expensive for me
That is why I decided to do this project only when I learned about burst determinism.

 

That's only the case if the steam p2p goes through their relay servers - if i recall correctly there are some settings regarding whether you allow use of a relay server or not (I think I disabled them for my game, as my bandwidth requirements are beyond the relay servers' support). In the vast majority of cases it'll make a direct connection which is not throttled. It uses steam servers for NAT punchthrough etc facilitating the connection.

 

This is the option I am currently considering. I still have to rewrite the project, but that way I can at least release it.

However ... I have not found any information on actual Steam bandwidth anywhere. I could only find k_EP2PSendReliable (1MB per channel). However, I have not found anywhere a mention of whether Steam itself limits traffic.Only assumptions.

Yes, looking at some threads, it seems that the only limitation is 1MB / sec. However, I still doubt this, since all paid servers offer traffic at fairly high prices. Steam is a free solution.

If you could share some practical data, it would be great: what kind of bandwidth are you talking about? Are there any specific numbers (SM p2p limits, direct connection, your traffic)?

 

That 1 MB for reliable messages is per message, not per time unit. I've send over 10 MB/s (my internet max) using it, no problem. Actual bandwidth max on the relay servers; I don't know, it indeed doesn't seem to be documented. My assumption has been that it's like 50-100 KB/s and it wouldn't fit my use case at all, so I just disabled it. Steam isn't free if you have sales

P.S: I'm talking about the 'legacy' API here, not the newer datagram/sockets stuff.

 

Thanks for the specifics.

This is unexpected: yesterday I and several of my friends tested sending large traffic through Steam: when the traffic reached 1MB, the packets seemed to "queue up" at the recipient and in fact he could only receive 1MB of a second. And this limitation is common and is shared by all running clients on one device (sandboxie test). But I used the Mirror wrapper, maybe I should take a look at pure Steamworks or Steamworks.NET.

50-100 KB - yes, that's not much, but still cheaper than paid traffic.
However, the Steamworks documentation states that it is not always possible to establish a direct connection. It looks like I'll have to take this into account.

But you gave me hope: if you are able to successfully transfer 10MB / sec (which is about 20 times the theoretical maximum traffic of my game and I hope for 5 clients x 100 KB / sec), then I can not be afraid and transfer my project to full synchronization (of course with optimization). Thanks for the info.

It seems that in 2021 it is not necessary to operate on lockstep determinism and we can synchronize literally everything. This is great news and a good decision for me, since there is no determinism in Burst.

Yes, but still cheaper than paid counterparts (I looked yesterday - the average price is ~ 0.1 $ / GB.

(In this post B is Byte, not Bit)

 

For networked physics you still need as much determinism as possible and will find that player count and update rate have a big effect. Being able to pack all you inputs inside the MTU is also better. You will also find that the more complex your game is the harder it becomes to synchronize smartly good luck.

Make sure you still have a heart beat even for stuff you think will remain static because physics easily desyncs.

 

Burst, NativeContainer and Unsafe code allowed me to do this task surprisingly quickly. I made a test project: 2500 units, position synchronization 2 times per second. The synchronization itself is also optimized (for example, instead of quaternion, I use 1 byte, where possible, etc.). In the end, I got good results. Thanks to Burst, I can instantly iterate over all entities and write to the array only those whose position has changed. Etc. I ended up with 25-40 KB / sec and 2ms in the editor without Burst. Of course this is a "clean project", but it's still pretty good.

Moreover, due to the abandonment of determinism, I increase (actually a little, a couple of ms) optimization at some points where determinism forced me to use one thread (not the main thread).

And so far I like this method more of determinism: I have more freedom. If I do not encounter problems with sending an average of 50KB / s to each client (x5), that is, 250KB / s, which is 4 times less than the limit, this is really convenient. Of course, we are talking about a PC and unlimited user traffic. However, do I have a choice? There is no determinism, and the use of various FixedPoint libraries shows me at least a hundredfold worsening of optimization in real simulations (not in the editor).
Of course, I have just started to transfer my project and will not finish soon, since I have to rewrite literally everything. Perhaps I will still run into problems.

However, I still use some predictions: for example, if a unit moved forward the same distance as in the previous frame, instead of reporting its position, I only send a message with its ID, which tells the client that he should move the units by the same value, as in the last frame. It's non-deterministic, so after 10 of these messages, I send a full frame.

 

I don't know why you need to rewrite everything. If you are smart about it client side prediction should not have to be that different then determinism. Just instead or rolling back the sim and apply new inputs you roll back to an old world and apply actual positions. Obviously you can network stuff a million different ways but if you are smart about it client side prediction vs determinism are very similarly architecturally. Get control of your world update and go from there.

 

When I created the project, I wrote code "especially for it": for determinism. Right now I see several improvements that I can make since I don't have to worry about the same state of the world.

Also, the prediction system in my case will be different. Why do I need to calculate RVO Steering (local unit avoidance) on clients and reduce their optimization? If in the end the 5-10kbps I get doesn't really matter? I use interpolation on units and extrapolation on fast projectiles. Yes, this is a "very easy" way.
But if I really don't need to worry about traffic (due to desyncs, I doubt that I can save even half the traffic), I can leave all the logic on the server side. And now, for example, real-time navmesh restructuring becomes available to me. I used to be afraid that it might be undetermined. There are several such examples.
In fact, to some extent, I'm a little happy that I can now expand my game (make a change to the terrain, etc.). But, I am still afraid that I might run into subtle problems with this approach.

 

Ok I have used an advanced form of dead reckoning in the past. These types of systems are ok for projectiles but client side prediction is better. In the end I have found that while you can optimize in this way you are in for a world of hurt do to the extra complexity of networking everything in the most optimized way. In the end you will end up with a inferior and highly complex product. Really think hard about what you are doing. Better to reduce unit counts.

 

Well... if I really don't have to worry about traffic (if 100kbps it's normal), I don't fully understand the potential problems: I might sacrifice some small visual fidelity since my game is a strategy. While writing a new synchronization system for a "partially deterministic" system seems to me even more suffering.

However, thanks for the advice, I will try to test the game as often as possible and first try to transfer the visual part, so that if I run into a problem, I don't fall into the same trap as with determinism (I learned about the problem when the game was almost ready for alpha versions). Still, I still have little experience in this part.

Unfortunately, reducing the number of units means completely changing the project. As planned, there should be at least 1k units on the screen, on average 3-5k, the largest maximum on powerful devices - 10k.

 

Hello, may I know what interface of steamworks you eventually chose? SteamNetworking or SteamNetworkingSocket? Could the bandwitdh meet your requirement? Is there a limit?
I am also making a game consume a lot of bandwidth, thank you.

 

Hi,

At this point I am using the usual way from FizzySteamworks by transferring bytes. I don't know what he is using internally.
As for the bandwidth: legacy connection (p2p) is limited to 1 megabyte per second (1024KBps) for the entire channel (that is, divide by the number of players excluding the host). However, connecting using the new method (direct) only allows transferring 1 megabit per second (128KBps) (divided by the number of players).

I tested this by sending a specific number of bytes, incrementing it until packets were queued.

This is my test data and has not been verified by any material from Steamworks. This means that my tests may be incorrect and the results may differ from reality. I have not found answers to these questions in their documentation.

 

I have not actually used the new networking yet I use Steamworks.Net directly. I plan to port to my code to UDP like ISteamNetworkingMessages.

I believe you can set your bandwidth limit in ISteamNetworkingUtils using ESteamNetworkingConfigValue.

 

Do you mean the settings in the Steamworks.Net utility classes?
This class has constants that specify and limit the maximum packet size and bandwidth. However, they work on the C # side - they check the size of the byte array and throw an exception if the array is too large. I've tried increasing these variables, which are set to 1 megabyte by default. When using p2p, this did not help and did not increase the throughput. However, when I started testing the direct connection, I used the default settings (that is, 1 megabyte). But when trying to send more than 1 megabit, the packets that followed after 1 megabit were delayed and arrived only the next second. This delay has accumulated and I can only get 1 megabit per second. Steamworks did not show any errors.

Unfortunately now I do not remember the details (names of classes and constants).

 

Don't send packets large then the MTU. You need to break stuff up. Also don't send lots of tiny packets. Turn Nagle off.

https://partner.steamgames.com/doc/api/steamnetworkingtypes
https://partner.steamgames.com/doc/api/ISteamNetworkingUtils

etc...

Code (CSharp):

1.     k_ESteamNetworkingConfig_Invalid = 0,
2.  
3.     /// [global float, 0--100] Randomly discard N pct of packets instead of sending/recv
4.     /// This is a global option only, since it is applied at a low level
5.     /// where we don't have much context
6.     k_ESteamNetworkingConfig_FakePacketLoss_Send = 2,
7.     k_ESteamNetworkingConfig_FakePacketLoss_Recv = 3,
8.  
9.     /// [global int32].  Delay all outbound/inbound packets by N ms
10.     k_ESteamNetworkingConfig_FakePacketLag_Send = 4,
11.     k_ESteamNetworkingConfig_FakePacketLag_Recv = 5,
12.  
13.     /// [global float] 0-100 Percentage of packets we will add additional delay
14.     /// to (causing them to be reordered)
15.     k_ESteamNetworkingConfig_FakePacketReorder_Send = 6,
16.     k_ESteamNetworkingConfig_FakePacketReorder_Recv = 7,
17.  
18.     /// [global int32] Extra delay, in ms, to apply to reordered packets.
19.     k_ESteamNetworkingConfig_FakePacketReorder_Time = 8,
20.  
21.     /// [global float 0--100] Globally duplicate some percentage of packets we send
22.     k_ESteamNetworkingConfig_FakePacketDup_Send = 26,
23.     k_ESteamNetworkingConfig_FakePacketDup_Recv = 27,
24.  
25.     /// [global int32] Amount of delay, in ms, to delay duplicated packets.
26.     /// (We chose a random delay between 0 and this value)
27.     k_ESteamNetworkingConfig_FakePacketDup_TimeMax = 28,
28.  
29.     /// [connection int32] Timeout value (in ms) to use when first connecting
30.     k_ESteamNetworkingConfig_TimeoutInitial = 24,
31.  
32.     /// [connection int32] Timeout value (in ms) to use after connection is established
33.     k_ESteamNetworkingConfig_TimeoutConnected = 25,
34.  
35.     /// [connection int32] Upper limit of buffered pending bytes to be sent,
36.     /// if this is reached SendMessage will return k_EResultLimitExceeded
37.     /// Default is 512k (524288 bytes)
38.     k_ESteamNetworkingConfig_SendBufferSize = 9,
39.  
40.     /// [connection int32] Minimum/maximum send rate clamp, 0 is no limit.
41.     /// This value will control the min/max allowed sending rate that
42.     /// bandwidth estimation is allowed to reach.  Default is 0 (no-limit)
43.     k_ESteamNetworkingConfig_SendRateMin = 10,
44.     k_ESteamNetworkingConfig_SendRateMax = 11,
45.  
46.     /// [connection int32] Nagle time, in microseconds.  When SendMessage is called, if
47.     /// the outgoing message is less than the size of the MTU, it will be
48.     /// queued for a delay equal to the Nagle timer value.  This is to ensure
49.     /// that if the application sends several small messages rapidly, they are
50.     /// coalesced into a single packet.
51.     /// See historical RFC 896.  Value is in microseconds.
52.     /// Default is 5000us (5ms).
53.     k_ESteamNetworkingConfig_NagleTime = 12,
54.  
55.     /// [connection int32] Don't automatically fail IP connections that don't have
56.     /// strong auth.  On clients, this means we will attempt the connection even if
57.     /// we don't know our identity or can't get a cert.  On the server, it means that
58.     /// we won't automatically reject a connection due to a failure to authenticate.
59.     /// (You can examine the incoming connection and decide whether to accept it.)
60.     k_ESteamNetworkingConfig_IP_AllowWithoutAuth = 23,
61.  
62.     //
63.     // Settings for SDR relayed connections
64.     //
65.  
66.     /// [int32 global] If the first N pings to a port all fail, mark that port as unavailable for
67.     /// a while, and try a different one.  Some ISPs and routers may drop the first
68.     /// packet, so setting this to 1 may greatly disrupt communications.
69.     k_ESteamNetworkingConfig_SDRClient_ConsecutitivePingTimeoutsFailInitial = 19,
70.  
71.     /// [int32 global] If N consecutive pings to a port fail, after having received successful
72.     /// communication, mark that port as unavailable for a while, and try a
73.     /// different one.
74.     k_ESteamNetworkingConfig_SDRClient_ConsecutitivePingTimeoutsFail = 20,
75.  
76.     /// [int32 global] Minimum number of lifetime pings we need to send, before we think our estimate
77.     /// is solid.  The first ping to each cluster is very often delayed because of NAT,
78.     /// routers not having the best route, etc.  Until we've sent a sufficient number
79.     /// of pings, our estimate is often inaccurate.  Keep pinging until we get this
80.     /// many pings.
81.     k_ESteamNetworkingConfig_SDRClient_MinPingsBeforePingAccurate = 21,
82.  
83.     /// [int32 global] Set all steam datagram traffic to originate from the same
84.     /// local port. By default, we open up a new UDP socket (on a different local
85.     /// port) for each relay.  This is slightly less optimal, but it works around
86.     /// some routers that don't implement NAT properly.  If you have intermittent
87.     /// problems talking to relays that might be NAT related, try toggling
88.     /// this flag
89.     k_ESteamNetworkingConfig_SDRClient_SingleSocket = 22,
90.  
91.     /// [global string] Code of relay cluster to force use.  If not empty, we will
92.     /// only use relays in that cluster.  E.g. 'iad'
93.     k_ESteamNetworkingConfig_SDRClient_ForceRelayCluster = 29,
94.  
95.     /// [connection string] For debugging, generate our own (unsigned) ticket, using
96.     /// the specified  gameserver address.  Router must be configured to accept unsigned
97.     /// tickets.
98.     k_ESteamNetworkingConfig_SDRClient_DebugTicketAddress = 30,
99.  
100.     /// [global string] For debugging.  Override list of relays from the config with
101.     /// this set (maybe just one).  Comma-separated list.
102.     k_ESteamNetworkingConfig_SDRClient_ForceProxyAddr = 31,
103.  
104.     //
105.     // Log levels for debuging information.  A higher priority
106.     // (lower numeric value) will cause more stuff to be printed.
107.     //
108.     k_ESteamNetworkingConfig_LogLevel_AckRTT = 13, // [connection int32] RTT calculations for inline pings and replies
109.     k_ESteamNetworkingConfig_LogLevel_PacketDecode = 14, // [connection int32] log SNP packets send
110.     k_ESteamNetworkingConfig_LogLevel_Message = 15, // [connection int32] log each message send/recv
111.     k_ESteamNetworkingConfig_LogLevel_PacketGaps = 16, // [connection int32] dropped packets
112.     k_ESteamNetworkingConfig_LogLevel_P2PRendezvous = 17, // [connection int32] P2P rendezvous messages
113.     k_ESteamNetworkingConfig_LogLevel_SDRRelayPings = 18, // [global int32] Ping relays

 

Since my game is a strategy with a large number of units, and I wrote the serialization myself, I bundle the data into the largest possible packages.
I experimented with different packet sizes and settled on 50KB / packet (this is the peak load, I usually send a smaller size). I am sending 10 packets per second (or more if a huge packet needs to be split). I tried to change the packet size and sending frequency, but this did not affect the limitation that I encountered (except for the error when the packet size is exceeded by several hundred kb).

Unfortunately, I haven’t learned anything that doesn’t apply to c # plugins (Steamworks.Net) and didn't look at the low level API. Thanks, I'll see it later. Maybe I'm missing something.

 

I don't think it is a Steamworks limit. You should make a example and send a bug report to Steamworks.Net. Setting k_ESteamNetworkingConfig_SendRateMax and k_ESteamNetworkingConfig_SendRateMin to 0 should give you unlimited.

 

I did it, but for FizzySteamworks:
https://github.com/Chykary/FizzySteamworks/issues/17

Yes, I definitely need to go to Steamworks.Net and experiment some more as soon as I can get back to this question.

This is really strange, because the new technology should not be 8 times "worse" than the old one.
Unfortunately, by that time I had to leave this project for a while, so I never asked a question about the limitations directly to support Steam. And nobody answered me on the Steamworks forum.

 

Steamworks.net looks like it has fixes recently. https://github.com/rlabrecque/Steamworks.NET/releases

Also Steamworks.net is really close to Steamworks API style so you can use Steamworks docs and examples and even has a .unitypackage.

The new networking is really new at least for Steamworks.Net. Steamworks.Net is always behind Steamworks and could have bugs still.

 

As far as I'm aware, the "new" steam API @ ISteamNetworkingMessages / ISteamNetworkingSockets doesn't have automatic bandwidth estimation yet. Setting it to unlimited would mostly break the connection if you tried to use more than physically available. Which made it pretty bad for my use case.

The "old" API @ ISteamNetworking doesn't have that problem at all for me. It "just works", besides taking 3 seconds to start up the connection. It scales nicely. (I've also set UseRelay to false)

You can also send packets above MTU no problem, if they're marked as reliable delivery, for both APIs. Maximum then is I believe 512 KiB or 1 MiB per packet.

I'm not aware of a 1 MB/s limit on the old p2p API, that may be the limit on the relay server connections there though. Or maybe I just didn't run into it yet for my use case. If you'd ask me, I'd say that if the p2p api ends up succeeding in getting a direct connection, it's unlimited.

We did get quite off topic here btw

 

I am wondering whether all kinds of connection in new steam socket api would use a relay server, or a direct p2p connection would be establish if it is possible. If the latter policy is true, the new api is still considerable. But given that all IPs are hiden, maybe the first policy is the situation.

 

I used to use facepunch.steamworks. However I found some bugs and it is out of maintain for a year. So I switch to Steamworks.Net. Although it is a bit low level, you can get a API more up to date. And search everything in steamworks document. It's worth a try.

Edit: I switch back to facepunch.steamworks, build from source. lol. there seems to be a native bug in SteamNetworksUtils.SetConfigValue in Steamworks.Net

 

It's a client setting for the new API, see the later paragraphs here https://help.steampowered.com/en/faqs/view/1433-AD20-F11D-B71E

Edit: you can of course just use the socket/connect by IP methods instead of the P2P ones

 

Wow, this is very useful, thanks a lot!

My game is a multiplayer game with player hosting, so I need to use steam's NAT traversal service to make player who don't own a public IP could host a game. However I haven't investigate what are situations that NAT traversal would fail. Maybe family would succeed, while ISP router would fail?

 

Will It Consider Support on Mobile Platform ?

 

Have you considered using fixed point math for deterministic logic?

Reimplementing floating point functions like `sqrt` or `sin` might be a pain, but it's definitely possible. It's not even that slow, for example here's `sqrt` implementation on int which is just 2x slower than classic `sqrt` function.

https://stackoverflow.com/questions/4930307/fastest-way-to-get-the-integer-part-of-sqrtn

 

This is a terrible idea. For so many reasons may as well just switch to C++. It is not even a serious option.

 

Maybe you can try to explain things, instead of writing your unsupported opinions.

Fixed-point has a history of use in lock-step RTS games, which rely on determinism.
Factorio uses that as well. There are even fixed math libraries for C# (and some of them completely covered with Unit tests).

It has disadvantages, notably the speed of some operations, but most basic operations are as fast as floating point. There are SIMD int instructions as well, supported by Burst.

It's main advantages are determinism, absence of sum errors and same precision over whole range.

 

What advantage does fix point have over C++ for determinism. It only has disadvantages. You have to write all physics code from scratch either way.

Fix point does not have a glorious history it has very limited utility in a few unmemorable hobbyist C# games.

Trig functions become jagged messes. All kind of serious problems you are not addressing and probably don't even fully understand the implications.

 

Unmemorable hobbyist games? That's a pretty harsh statement. Photon quantum uses fixed-point math as well.

 

Comparing C# fixed point to C++ floating point doesn't make much sense, but since you asked it: it can give you (cross platform) determinism easily. You don't need to rely on IEEE 754, exactly same compiler settings and FPU float flags.

While some games might need deterministic physics, it's not common in RTS. Starcraft 2 has non-deterministic physics and it's fine, because physics does not affect game logic, it's there just to "animate" dead units. SC2 uses 20.12 fixed point (20 bits for integer part, 12 bits for decimal) btw.

I wouldn't call Starcraft 2 hobbyist and it's definitely not written in C#...

Depends on the usage of trigonometric functions, in many cases precision is enough. In other cases you can use higher precision fixed point numbers, like 32.32 or 48.16 for intermediate results. And you can always store things like "unit heading angle" as normalized 2-byte integer.

I don't understand why we're talking about C++ here? Language doesn't matter, you can use both fixed point and floating point in both languages.

 

Literally almost every single RTS from Age of Empires on have used deterministic floating point C++. I can literally name hundreds of titles; that use determinist C++ it works and its great. Fixed point math is literally junk.

Do you have a credible source that says SC2 uses fixed point because I highly doubt it.

https://gafferongames.com/post/floating_point_determinism/

Use the right tool for the job.

 

Fixed point math as a solution to determinism seems to mostly come up in context of
- cross-platform hw differences (arm/x86 32/64bit win/linux etc)
- tooling doesn't support it (like C# JIT not having the proper flags, running WASM, other JITs/interpreters/compilers)
there's probably a bunch of games doing it for those reasons.

If you have one platform (say modern 64-bit x86 stuff supporting SSE2 + SSE4), it seems approachable using specific compiler flags available on c++ re: strict floating point modes, making sure it uses SSE instead of x87 FP and such

 

James Anhalt (lead on path-finding and probably other key tech in SC2) GDC presentation 'AI Navigation: It's not a solved problem yet' from 2011 @~14:50 the slide says:

"Physics Simulation
All done using fixed point maths"

I'm using fixed point maths for physics myself and did have some pain with jitter/precision issues before so I get where you're coming from.