The best part of this article is in the comments. An original programmer on the game explains the reason that the bug was occurring and also why the code was unreadable (hint: they did it in assembly)
Ah, the quantum tunneling pinball!
We ran into this while writing the original code at Cinematronics in 1994. Since the ball motion, physics, and coordinates were all in floating point, and the ball is constantly being pushed "down" the sloped table by the gravity vector in every frame, we found that floating point error would gradually accumulate until the ball's position was suddenly on the other side of the barrier!
(To simplify collision detection, the ball was reduced to a single point/vector and all barriers were inflated by the ball radius. So, if the mathematical point got too "close" to the mathematical line barrier, a tiny amount of floating point rounding or truncation error could push the point to the other side of the line)
To mitigate that, we added a tiny amount of extra bounce to push the ball away from the barrier when it was nearly at rest, to keep the floating point error accumulation at bay. This became known as the Brownian Motion solution.
Since much of the original code was written in x86 asm to hand tailor Pentium U/V pipelines and interleave FPU instructions, but wiki says Microsoft ported the code to C for non-Intel platforms, I'm sure the code had passed through many hands by the time it got to you. The Brownian Motion solution may have been refactored into oblivion.
I've had similiar problem in one of my first games (scrolling shooter with asteroid physic, hobby project in TP7 and mode 13h), and I solved it in similiar way (when objects bounced off the obstacle I added constant to response vector length, so that ship always bounced with velocity so big, that even with gravity added, and when player rotated towards the obstacle and engaged engine, it would still move out of the obstacle in next frame).
It looked a little funny, cause when you left the ship to itself, it bounced in a place to half its height and back forever.
To mitigate this I've added 2 kinds of obstacles - most of the terrain was filled with obstacles with spikes, that did damage on each collision, so players won't test my collision response too much :) There were some obstacles without spikes, and you could forever bounce on them, but they were rare, and I marked them as "landing places". I think that added to gameplay.
Then I've added buttons that trigger doors to open/close, and in a few levels I've just placed some ship with no ai attached over the button. Effect - ship bounced forever, so the doors connected to the button opened and closed repeatedly ;) Player could also influence that by pushing the triggering ship away :)
It's funny how constraints of game engine can guide you into gameplay elements that you wouldn't consider without them.
Maybe the reason the Brownian motion stopped working was a shift from 80-bit x87 intermediaries to 64-bit SSE in x64, and the removal of long double support from MSVC.
As a matter of fact, there is still a quantum tunnel bug. If you push and release the flippers too fast, the ball goes through them. Not a big deal unless you want to control the ball the same fine-tuned way as with real machines.
BTW, it works OK with Windows 7 (64), just copying it from an old installation. I like the game... 170M :-)
Ah, the quantum tunneling pinball!
We ran into this while writing the original code at Cinematronics in 1994. Since the ball motion, physics, and coordinates were all in floating point, and the ball is constantly being pushed "down" the sloped table by the gravity vector in every frame, we found that floating point error would gradually accumulate until the ball's position was suddenly on the other side of the barrier!
(To simplify collision detection, the ball was reduced to a single point/vector and all barriers were inflated by the ball radius. So, if the mathematical point got too "close" to the mathematical line barrier, a tiny amount of floating point rounding or truncation error could push the point to the other side of the line)
To mitigate that, we added a tiny amount of extra bounce to push the ball away from the barrier when it was nearly at rest, to keep the floating point error accumulation at bay. This became known as the Brownian Motion solution.
Since much of the original code was written in x86 asm to hand tailor Pentium U/V pipelines and interleave FPU instructions, but wiki says Microsoft ported the code to C for non-Intel platforms, I'm sure the code had passed through many hands by the time it got to you. The Brownian Motion solution may have been refactored into oblivion.
http://blogs.msdn.com/b/oldnewthing/archive/2012/12/18/10378...