Linked by Thom Holwerda on Tue 18th Dec 2012 23:12 UTC
Windows "Windows XP was the last client version of Windows to include the Pinball game that had been part of Windows since Windows 95. There is apparently speculation that this was done for legal reasons. No, that's not why." I love these stories.
Thread beginning with comment 545835
To read all comments associated with this story, please click here.
read the comments
by transputer_guy on Wed 19th Dec 2012 07:04 UTC
transputer_guy
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.

Reply Score: 4

RE: read the comments
by henderson101 on Wed 19th Dec 2012 09:54 in reply to "read the comments"
henderson101 Member since:
2006-05-30

If you read the secondary link, Raymond actually fixed it to work nicely on the NT WIN32 strand. It otherwise consumed 100% of the processor and had a ~1000FPS refresh rate!

My guess is that a pinball game wasn't an especially hight priority.

Reply Parent Score: 4

RE[2]: read the comments
by MOS6510 on Wed 19th Dec 2012 12:56 in reply to "RE: read the comments"
MOS6510 Member since:
2011-05-12

My guess is that a pinball game wasn't an especially hight priority.


Unlike the refresh rate!

Reply Parent Score: 2

RE: read the comments
by renox on Thu 20th Dec 2012 10:22 in reply to "read the comments"
renox Member since:
2005-07-06

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.


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

Reply Parent Score: 3

RE[2]: read the comments
by Alfman on Thu 20th Dec 2012 13:14 in reply to "RE: read the comments"
Alfman Member since:
2011-01-28

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.

Reply Parent Score: 2

RE: read the comments
by Alfman on Thu 20th Dec 2012 15:45 in reply to "read the comments"
Alfman Member since:
2011-01-28

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

Reply Parent Score: 2