Box2D Forums

It is currently Thu Jul 24, 2014 8:37 pm

All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Tue Jun 23, 2009 2:28 pm 
Offline

Joined: Mon Jan 07, 2008 10:51 am
Posts: 1911
Box2D uses hand coded containers, and is single threaded. It fulfils most strong definitions of determinism.
We do not say so as a) no developer is willing to support this, when it can be such a thorny issue, b) there's internal state that cannot be easily recreated (ordering of objects in containers, warm starting) - so no save/load/sync.

It's really that simple.


Top
 Profile  
 
PostPosted: Wed Jun 24, 2009 6:36 am 
Offline

Joined: Fri Sep 28, 2007 7:49 am
Posts: 61
@eemerson: What?! I had always assumed that cross-platform deterministic fp was impossible. How did you deal with the "Intel uses 80bits of precision internally" problem? The "DirectX likes to change fp modes" problem? The "each platform has its own transcendental functions implementation" problem?!

That you managed this on different processors (intel/amd as well as ppc) is really impressive. This is something that I think many people would LOVE to see a tutorial or GDC presentation on.


Top
 Profile  
 
PostPosted: Thu Jun 25, 2009 12:40 am 
Offline

Joined: Mon Jun 22, 2009 11:27 pm
Posts: 4
oh I should explain the target platforms in more detail.

We built Supreme Commander 1, then DemiGod in-house using the same engine. Another company ported that engine to the 360 platform to ship Supreme Commander 1 on 360. All three of those shipped games are networked via peer to peer where each client does its own physics, pathing, etc so we rely heavily on the floating point processor being 100% deterministic on both platforms.

Howeva! The 360 port of SupCom does not network with the PC version. Only game I can think of that does that craziness is ShadowRun, which is a server client networked game so the server can fix up.

So, sorry to mislead you with my inital description, we are not doing anything GDC worthy there. =)

My main goal is to squash all the worry out there about the floating point processor not being deterministic. The rounding error is going to be the same for all clients per IEEE standard and we ship games based on that. So ya, you heard it from a someone who works on this stuff and ships games on it. The floating point processor is not a problem.

It's possible to make physics deterministic. don't give up! =)

All this talk about fixed point or ints or whatever has got to go.

Instead.. get ninja on it and spit out tons of logs and CRC checks per tick, find where the bits start to change and why then fix those cases. After the initial pain.. it feels dang good to have your physics code work the same across all machines and replays without storing anything but input actions.

Then you can claim what few physics solutions can, deterministic physics.


Top
 Profile  
 
PostPosted: Thu Jun 25, 2009 10:42 am 
Offline

Joined: Thu May 08, 2008 12:33 pm
Posts: 25
I just checked on two different Intel processors and two different ones from AMD. Summing all sqrt-s from 0 to 15 in increments of 0.001 yields the same results on all 4 processors. Therefore I assume that if you use the same initial state (including the internal state of the library) with floating or fixed point and fixed time-step you will get complete determinism. That is of course granted there are no time-seeded rands, but I think Box2D doesn't.


Top
 Profile  
 
PostPosted: Thu Jun 25, 2009 3:36 pm 
Offline
Site Admin

Joined: Thu Sep 06, 2007 12:34 am
Posts: 2946
It seems people are overloading the word "deterministic". Box2D is already deterministic. Give a specific build, PC, and initial conditions, you will always get the same simulation.

The issue we are concerned about is reproducibility. Can a result on an AMD PC be reproduced on and Intel Mac?

The IEEE standard makes guarantees about rounding etc. So basic arithmetic should be identical.

You have to use certain compiler flags to enforce the standard. For performance, we also need to turn of denormalized numbers. I'm not sure if this is handled the same way on AMD and Intel processors.

I wonder if all trig functions are giving the same answer on AMD and Intel.

Getting reproducibility is not just a matter of rolling up your sleeves. It is also required to have proper compiler support and to have all the platforms available for testing.


Top
 Profile  
 
PostPosted: Mon Jun 29, 2009 9:28 am 
Offline

Joined: Tue Sep 11, 2007 7:26 am
Posts: 95
as someone who doesn't know anything :) wouldn't it be better to just work and make a really great fixed point
version where you wouldn't know the difference between fixed and float? then all the reproducible errors would go
away ..abstracted out instead of all that crc checking and ninja debugging?
unless it's harder to do that than all that debugging..


Top
 Profile  
 
PostPosted: Tue Jun 30, 2009 9:29 pm 
Offline

Joined: Mon Jun 22, 2009 11:27 pm
Posts: 4
Thanks for chiming in Erin! Was wondering what your take was on this topic.

The whole point of my post was to let everyone know that the fpu reproduces the same results given a fixed time step in our games. That’s really it.

I felt based on my work experience I could get people to steer away from the idea that you need to have fixed point to solve this problem. Just to feel sane, I double checked with my lead as well as our network programmer and they both agreed that there are no compiler flags needed to reproduce the same results across machines. Howeva!

There *is* something I missed!!!

They pointed out to me that we must manually set the fpu mode through _controlfp() so the fpu mode is the same across machines.

At app startup time we call:

_controlfp(_PC_24, _MCW_PC)
_controlfp(_RC_NEAR, _MCW_RC)

_controlfp() description:
http://msdn.microsoft.com/en-us/library/e9b52ceh(VS.80).aspx

Also, every tick we assert that these fpu settings are still set:

gpAssert( (_controlfp(0, 0) & _MCW_PC) == _PC_24 );
gpAssert( (_controlfp(0, 0) & _MCW_RC) == _RC_NEAR );

There are some MS API functions that can change the fpu model on you so you need to manually enforce the fpu mode after those calls to ensure the fpu stays the same across machines. The assert is there to catch if anyone has buggered the fpu mode.


FYI We have the compiler floating point model set to Fast /fp:fast ( but its not a requirement )

We have never had a problem with the IEEE standard across any PC cpu AMD and Intel with this approach. None of our SupCom or Demigod customers have had problems with their machines either, and we are talking over 1 million customers here (supcom1 + expansion pack). We would have heard if there was a problem with the fpu not having the same results as replays or multiplayer mode wouldn't work at all.

We did however have problems when using some physics APIs because their code did not have determinism or repoducability 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.

Well i better wrap up i type too much. I don't usually post in forums but I thought I had a unique perspective on this topic that would help my fellow game devs out. If, after this post I have not convinced you that the fpu is safe across PC machines and 360s well.. I'm not sure what post will. =)

At the end of the day, I hope I’ve helped someone out there.

Thanks Erin for making Box2D open source and supporting it over the years. can't wait to see what you and the other guys working on will do next. I've been wanting to see 2d physics games done well for so long!


Top
 Profile  
 
PostPosted: Tue May 22, 2012 5:33 pm 
Offline

Joined: Tue Apr 03, 2012 9:07 am
Posts: 6
Hi, I've been trying to get this working. I usually stay in high-level land so all I know about this is what I've been reading over the last week.

I am working on multiplayer for an iPhone and iPad game. For testing purposes, I'm playing between an iPad and my macbook running the iPhone simulator, sending only user input back and forth and synchronizing each command to the same game tick on each device. I need to get them running exactly the same given the same input.

What I found was that the simulation did run exactly the same as long as I stuck to simple math like add, multiply, divide and subtract. When I used sin(), cos(), atan2(), sqrt() and pow() there were slight cross-platform differences that built up.

It turned out I was using the versions of those methods that took floats, like sinf(), cosf(), etc. I switched to using doubles and the versions of those methods that take doubles (sin(), cos(), etc). The cross-platform differences were still there, but they became much smaller. When I take the results of those methods and send them to Box2D, they get converted to floats by Box2D and the differences seem to get chopped off.

The final fix was to change Box2D's own math to use the double versions of the methods too. I changed b2Math.h in a few places to use sin() and cos() instead of sinf() and cosf(), and atan2() and sqrt() instead of std::atan2() and std::sqrt().

Now everything seems to be exactly reproducible, even when tossing ragdolls around. I have no idea if what I did was correct or if there will be some corner cases where the simulations will desync due to rounding errors, or even if other chipsets will not be reproducible (but I'm hoping all the iOS-related ones are). Does anybody have any insight into that?


Top
 Profile  
 
PostPosted: Tue May 22, 2012 7:46 pm 
Offline

Joined: Sun Oct 25, 2009 3:28 am
Posts: 258
Good job on making them sync'd up! Have you tried running the simulation for a long time? The rounding differences tend to be accumulative as the simulation goes on.


Top
 Profile  
 
PostPosted: Tue May 22, 2012 10:36 pm 
Offline

Joined: Tue Apr 03, 2012 9:07 am
Posts: 6
jayther wrote:
Good job on making them sync'd up! Have you tried running the simulation for a long time? The rounding differences tend to be accumulative as the simulation goes on.


I haven't, fortunately for my game I only need to run the simulation for a minute or two at a time. I did log out all the values for position and angle for each body though, and they are exactly the same throughout, so if there are any differences at all I'm not sure how to see them.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group