OSNews

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