Arqade is a question and answer site for passionate videogamers on all platforms. It only takes a minute to sign up.
Sign up to join this community
I doubt it. Breakout on the Atari 2600 used analogue paddle controllers, which means the input from the controller itself is unlimited. There'd have to be code in the game to interpolate a slower speed and it's hard to see why the developers would want to allocate some of the very limited memory available for 2600 games on something like this. It also would imply that the authors of the paper cheated and modified the game to remove that hypothetical code. Given their goal isn't to beat Breakout but have a program learn to play Breakout cheating like this would be self defeating. If anything they should be adding code to limit the paddle speed and accuracy to what would be physically possible for a human.
I also vaguely remember paddle games of the era not being speed limited, but I don't think I ever played Atari 2600 Breakout. I don't think speed limiting became a thing until digital controls starting being used to for these games, which are inherently limited to whatever speed the developer chooses.
Paddle controllers on the Atari 2600 use a variable resistance in a resistor-capacitor timing circuit and then measure how long that circuit takes to switch. The time will vary from a few scan lines to a couple hundred scan lines, depending upon paddle position, and software will typically need to scan the controller position during the video frame. For games that use one paddle, its position will typically be sensed "from scratch" on every frame; games that use more will typically read paddle positions "in rotation". Games can typically sense any amount of paddle movement per frame, and many will respond directly to paddle movement.
In my own partially-completed variation of Arkanoid, I used a different approach to reading paddles which limited their speed. Rather than resetting the timing circuit at the start of each frame and checking on every other scan line whether it had timed out yet, I selectively set or clear the "reset" signal to the timing circuit on every 8th scan line, based upon the previous paddle position, and then I check for a timeout on each line during (IIRC) a 48-line area near the bottom (below the bricks). This reduces the overhead required to read the paddle during the displayed part of the frame (freeing up CPU time to display more content) but limits paddle motion to 32 pixels/frame. Even though the speed is not unlimited, it's still pretty fast (if memory serves, my version of the game was 144 pixel across, so about 1/10 second would let the paddle fully cross the screen).
I don't know if any other paddle games used this approach, but it reduces the CPU overhead required for paddle sensing at the expense of maximum paddle speed.
http://www.atarihq.com/reviews/2600/breakout.html :
You move your paddle left and right at the bottom of the screen. The speed of the video paddle is not limited, as in some games; it moves at the same rate as the paddle controller. The red button on the controller serves the ball to start each turn.
The video paddle (not to be confused with the paddle controller) is divided into four sections. Each section has a different rebound angle, so you can anticipate where the ball will go. However, the rebound angle becomes sharper after the eighth hit, then less sharp again after the sixteenth hit. After the forty-eighth hit the paddle is divided into only two sections, with each rebound angle being about 45 degrees. You'll have to gain a fair amount of expertise to make use of this information about the angles. At first, it will take all of your coordination just to get the paddle to hit the ball, never mind at what spot on the paddle. Also, attempting to hit the ball at the edge of the paddle often results in missing it altogether. The speed of the ball is not controllable, but does increase after the eighth hit and as the ball knocks out one of the bricks in the top four rows of the wall.
