A bit of bad TCP/IP news

[David Stone]

Alas, time for another beer...

Stoner

[sniperscope]

I have solved the problem. Just put the z buffering number in a zoned method output. This will cause the nanoCMx2 engine to go to a higher level of input instead of output. Then place the ISP target packit in a flash release model. Hope this helps BTS....hic

sniperscope

------------------

<BLOCKQUOTE>quote:</font><HR>When CM arrived, all other land based war games became crap.

sniperscope<HR></BLOCKQUOTE>

[Guest Madmatt]

No, it was not specific to Intel/AMD/Mac's. It affected them all.

In fact in one test both players had P3-800's and that's where we first noticed the issue.

There is also no worry about one system in normal PBEM giving better results than another. We are talking about hundreds of thousands of data points, any one of which could be a factor in a turns resolution. If anything this just goes to prove how impossible it is in to every get the exact same situation and result in the game twice.

It's just not as cut as dry as saying: "Oh my P2 500 always gives me better results since it rounds down."

Madmatt

[sniperscope]

Madmatt: I was kidding. I have been drinking and don't know what the F**k I am talking about, but it sounded techno geek cool. hahahahaahahaha

sniperscope

------------------

<BLOCKQUOTE>quote:</font><HR>When CM arrived, all other land based war games became crap.

sniperscope<HR></BLOCKQUOTE>

[CaSCa]

<BLOCKQUOTE>quote:</font><HR>Originally posted by Madmatt:

It's just not as cut as dry as saying: "Oh my P2 500 always gives me better results since it rounds down."

Madmatt<HR></BLOCKQUOTE>

Rats! That means I am a tactical dufus!

[Guest aaronb]

<BLOCKQUOTE>quote:</font><HR>Originally posted by aka_tom_w:

[...]Does anyone else on the board know how other programs or institutions deal with this?

I know this is Crazy but doesn't NASA have to sync computers on the ground and on the space shuttle (Doh! I guess they just buy the same cpu.)

<HR></BLOCKQUOTE>

If the issue is known right up front and the hit from simulating floats with integers is ok, you, uhm, simulate floats with integers (via scaling) or use, say, COBOL with BCD arithmetic and bind the routine into the rest of the 'C' code base. Matt said it best:

<BLOCKQUOTE>quote:</font><HR>In order to implement any other math technique (integers, shared data key sets etc..) would require a whole overhaul of the existing code structure and that is NOT an option. <HR></BLOCKQUOTE>

As far as IEEE 754, as suggested by Fuerte, it's a great idea but: http://www.validgh.com/goldberg/addendum.html

Anyway, Matt's right, retrofitting the code base would be a big job.

[-E]

Kudo's to BTS for laying it all out... sure makes a delay easier to swallow (and increases our dedication to BTS for trusting us with actual information versus the standard "just bump the date" news from others)

[Peterk]

> Thank god you found this problem! I'd much > rather play a slower TCP/IP game than a

> TCP/IP game that is inaccurate

I don't know - it would be kind of cool to have the games on each machine diverge at some point in time....

Anyone ever read this Woody Allen short story where 2 old guys are playing postal chess with one another, but one loses a move half-way through and they both end up playing different games and announce checkmate on the same move 6 months later?

If we use those TCP/IP drinking rules, most of us would probably not even notice the floating point things not floating enough.

p.

[Guest barrold713]

Too bad about the setback, but I have heard it said that one learns more from failure than success. In terms of this specific feature, perhaps it can be used for future versions of CM or a workable solution will eventually be found.

Thanks mostly for the update and for the respect you show for your customers by keeping everyone abreast of these sort of details.

BDH

------------------

"Democracy is two wolves and a lamb discussing what to have for lunch. Liberty is a well-armed lamb contesting the vote"

- Ben Franklin

[Guest Big Time Software]

Duri, I suspect the games you mentioned were using interger math and therefore there wouldn't be any problems. Also, the mistakes could be rather subtle and non-lethal. But it didn't take us long to find one that was lethal.

CaSCa, no advantage depending on CPU. It could just as easily cause a negative rounding as it would a positive one.

degreesK, the problem was first discovered between an Intel PIII and a AMD chip. If you know of some way to synch the two please give Charles an email about this (charles@battlefront.com).

Schrullenhaft, we thought about having two methods, but it causes internal complications as well as customer confusion. So it is best to have only one method. If we ever figure a way around the rounding problem we will change back to it for everybody.

Aaronb, the other problem is that using anything other than floating point is MUCH slower. So even if we redid the game engine, the overall results would be very disapointing. Especially for single and PBEM players who would have to take a CPU hit for no reason

Steve

[Trooper]

OK.. doubtless you've thought of this already and it has been rejected for whatever reason, but for my own curiousity I ask anyway...

TacOps PBEM files use a 'seed' number from which all future results are extrapolated by calculation. Each computer calculates the results of the turn separately, and yet, despite player A having a 486 33 and player B a G4, the turns are identical.

Why is such a system not feasible here? (Or have I missed the problem completely?)

NTM

------------------

The difference between infantrymen and cavalrymen is that cavalrymen get to die faster, for we ride into battle!

[Dschugaschwili]

<BLOCKQUOTE>quote:</font><HR>Originally posted by Trooper:

OK.. doubtless you've thought of this already and it has been rejected for whatever reason, but for my own curiousity I ask anyway...

TacOps PBEM files use a 'seed' number from which all future results are extrapolated by calculation. Each computer calculates the results of the turn separately, and yet, despite player A having a 486 33 and player B a G4, the turns are identical.

Why is such a system not feasible here? (Or have I missed the problem completely?)

NTM

<HR></BLOCKQUOTE>

Just what Steve said: If a game uses integer numbers in all calculations, sync'ing the random seeds works just fine.

Unfortunately, BTS has decided to use floating point numbers for the calculations in CM (of course, they can't be blamed for doing so), and you sadly can't expect two FPUs to give exactly the same results every time when doing floating point calculations. And as has been pointed out several times in this thread, even tiny differences in the last digit can cause the game to fall out of sync.

So I really think BTS is right claiming that there's no easy solution to the problem at hand.

Dschugaschwili

[Boogie]

It's great you keep us informed... we'll wait!!

[SS_PanzerLeader]

I recently ran across this in a program I was doing at school, and wondered if the internal floating point representations could lead to problems in programming calculations. This proves to be a very interesting discussion for me although not the best news

Is the difference in the number representations a constant for all numbers? ie does the difference between the representations == .000002 (arbitrary) consistantly for all calculations?

If so is there a way to compare the two and ensure the result becomes the same as intended? Maybe by compensating the differrence on the one machines calculations?

Just a thought but I'm still student so I always have questions If you can spare a second tho I would like to hear your thoughts on this

thanks

------------------

SS_PanzerLeader.......out

[tss]

Dschugaschwili wrote:

and you sadly can't expect two FPUs to give exactly the same results

To tell the truth, I don't expect one single FPU to give exactly the same result all times. (Yeah, they usually do but floating point calculations are suspiciously close to voodoo, in my opinion.)

The thing that makes floating point tricky is that almost all operations will add some amount of error to the calculations. This results in very unintuitive behavior of arithmetic.

For example, x + y is not equal to y + x in most cases except when x is much larger than y when x + y = x = y + x.

- Tommi

[tss]

SS_PanzerLeader wrote:

Is the difference in the number representations a constant for all numbers?

Nope. And as far as I know, there is no way to reliable predict the difference in the general case.

- Tommi

[Sitting Duck]

<BLOCKQUOTE>quote:</font><HR>Originally posted by Big Time Software:

...Let us say that a Panther needs to rotate its hull in order to defend against an enemy Sherman...the Panther has 5 seconds to rotate...On one machine it is calculated that the Panther manages to rotate its hull 19.0001 degrees, but due to the rounding problem on the other machine the Panther only rotates 18.9999 degrees...<HR></BLOCKQUOTE>

So...which CPU should I get to make my Panther turrets rotate faster?

------------------

Quack!

[GriffinCheng+]

BTS,

It is not surprising since P3 can't compute floating point math very well. I am not kidding. People tells a lot of stories about FPU problems, especially doing divisions....

Check this out: http://ars.userfriendly.org/cartoons/?id=20001107

Griffin.

------------------

"+" is just the beginning. Expect to see "GriffinCheng76", "GriffinCheng(105)" or "GriffinChengA3E8" more should Forum problems occur again

[Dschugaschwili]

<BLOCKQUOTE>quote:</font><HR>Originally posted by Sitting Duck:

So...which CPU should I get to make my Panther turrets rotate faster?

<HR></BLOCKQUOTE>

That's the wrong question! Asking which side you should play with the CPU you already have is much less costly.

Dschugaschwili

------------------

Erst hat man kein Glück, und dann kommt auch noch Pech dazu.

[Ol' Longhair]

Thanks Steve, Charles, and Team for your continued hard work and dedication to CM.

[Dschugaschwili]

<BLOCKQUOTE>quote:</font><HR>Originally posted by tss:

For example, x + y is not equal to y + x in most cases.

<HR></BLOCKQUOTE>

That's true, but it wouldn't be a problem here if the results were consistent on different FPUs. But of course all those heavy optimizations all manufacturers make to get a little more speed out of their FPUs sometimes lead to small differences in the results.

Dschugaschwili

------------------

Erst hat man kein Glück, und dann kommt auch noch Pech dazu.

[Pham911]

Correct me if I'm wrong, but if CM uses floating point numbers to calculate battles, and if floating point numbers are rounded differently depending on your CPU, doesn't this already impact gameplay between people? If turn 1 is processed by my computer, which gives a slightly faster turret rotation speed than my opponents(for example), then turn 2 is processed by him and the rotation is slower, doesn't this mean that my tanks have variable rotation speeds within the same game? Doesn't it also mean that between different opponents of mine that my tanks will perform differently, even if under the same battlefield conditions?

Someone said that there were millions of calculations per turn(I think it was millions, anyways). Wouldn't this amplify the problem if all those FP's were being rounded differently every other turn? I.E. I process turn 1 and all my tanks rotate slightly faster(and above what they are supposed to by design), and I score more kills. Turn 2, processed by my opponent, my tanks now rotate not only slower than normal, but also slower than they were when I processed the last turn, so I lose more tanks on average.

Just trying to understand. Any help appreciated.

[Cyrano]

Lessee, degree(s) in history...*nope*

Degree in journalism...*nuh-uh*

Degree in philosophy!!! Yes...uh...*no*

Degree in divinity? Sha...right...

Wonderful, now I'm even unqualified to understand what's wrong with my favorite game, or at least help devise a solution...

Regards,

Cyrano

Luddite-in-training

------------------

"Watching others make friends, as a dog makes friends. I mark the manner of these canine courtesies and say, 'Thank God, here comes another enemy'" -- Rostand

[Pug]

Yet another closet programmer's 2 cents:

Given that you probably don't really need the full precision you are getting from a 32 bit value why not simply wrap your FP functions with something like:

return (real_value & 0xfffffffc);

Masking the last two bits should ensure that the results are the same regardless of the inherent unpredictability of a given calculation.

The drawback is that you loose 2 bits of precision and add about 4-6 cycles to the operation.

BTW guys, it is never 'impossible to fix', but it is often too costly.

[Guest Madmatt]

Pham911,

That is not a problem as such when you look at it closely. What was occuring is that the game was sending the same data to two systems simulataneuously and they then took that data and generated the turn with it. The problem was they were coming back with slightly different results. There is no inherient advantage to one set of numbers or the other, they were just different. These different numbers then manifested themselves into each player seeing divergences in each playback. Think of it this way, save a turn right before you issue the GO command then reload it and play it back 10 times. You will get 10 COMPLETELY different movies each time. In a nutshell that was what was happening here. Charles thought he had come up with a way to guarantee that each system would get the same results at the same time for the same turn based on the same internal calculations, but it didn't work.

In a PBEM game only one system is doing all the number crunching at a time so there is no discrepancy. Steve's earlier example was really simplified down to make it easier to understand.

I hope that makes sense.

Madmatt