To read all comments associated with this story, please click here.
Sigh, and people still look at me as if I was a madman when I say that floating point suck and that we should use interval arithmetic..
http://en.wikipedia.org/wiki/Interval_arithmetic
renox,
"Sigh, and people still look at me as if I was a madman when I say that floating point suck and that we should use interval arithmetic.."
Very insightful. Beyond rounding issues, it's always bugged me a bit too that the resolution of game coordinates become worse and worse the further a player gets away from the origin. Therefor if your running precise mathematical computations in a game (ie object projections), the results inherently depend on which arbitrary digits the mantissa is representing. Using integral/fixed point arithmetic would offer equal precision at all coordinates.
transputer_guy,
"As the x86 evolved with ever new FPU opcodes and then AMD64, the FPU bugs became too difficult to figure out."
"There are various comments about the game using detection algorithms that were very sensitive to FPU round off errors eventually causing it to pass through solids."
Somehow this doesn't seem right, even though it's what the author hinted. And since he didn't find the bug, he might be wrong to point the finger to FP. How does FP rounding make a difference for a game where the ball's position is genuinely a REAL number (unlike currency)? What's it matter if a bit representing 0.000000000000000005% of the full value is a 1 or 0?
AMD64 still has the original 80bit floating point unit & registers used by x86. Some applications have switched to SSE's 64bit FP computation, but it isn't necessary and I am wondering if the bug is happening with both FPU and SSE?
My guess is that there's some timer initialization code that's buggy in the 64bit version which is causing the in-game motion vector factors to jump up such that the ball "moves" from above the paddle to below it in one game step without ever touching it.
Pseudo example:
intervals_per_second=0;
time = time();
while( time()-time < 1s ) {
ProcessGameInterval();
intervals_per_second++
}
This code determines how many steps the game can handle per second. However if the integer type is too small (say 8 or 16bits), then intervals_per_second will wrap. This would cause the game to *think* that the machine's is very slow, and ProcessGameInterval might move the ball by such large steps at each interval such that it completely misses the paddle.
Edited 2012-12-20 15:47 UTC





Member since:
2005-07-08
I suspect the game was perfectly well commented by the owner but were stripped out due to small license payment, why would MS need to understand code if they were barely paying for it after all it worked on the current hardware.
It was written in asm, maybe it was actually written in C but MS only was given the asm listing.
From the comments in the blog
The asm code was highly tuned to the FPU pipeline, paired ops and all.
As the x86 evolved with ever new FPU opcodes and then AMD64, the FPU bugs became too difficult to figure out.
Payment for the license was only a few thousand $
MSFT actually hoped that devs would pay them to add their games to the Win95 Plus pack for the exposure, didn't fly so most devs didn't join the Plus pack.
There are various comments about the game using detection algorithms that were very sensitive to FPU round off errors eventually causing it to pass through solids.