Hacker News Reader

Comment by ButlerianJihad | Hacker News Reader

I don't know about Space Invaders, but Pac-Man on the 2600 used incredible hacks that were widely criticized, but essential to cramming the spirit of the game into that tiny cartridge and puny machine.

Essentially, the 2600 gives the programmer 2 sprites only. One sprite is dedicated to drawing the Pac-Man main character, while the other takes the role of all four ghosts. That's right, simultaneously 1 sprite for 4 distinct ghosts, wherever they are on the screen.

This singular sprite and the practice of "racing the beam" leads to a lot of flickering. I believe that the flickering is so severe that it impacts the collision detection, so that Pac-Man can slide right through a ghost in the right place and time.

I owned a copy, of course, and it was just so sad to compare it with its daddy in the arcade cabinet. However, once Ms. Pac-Man rolled around, they had learned a lot of lessons, and made that one a rousing technical success.

View on HN

It's the other way around - 2600 Pac-Man didn't do any hacks and that's what made it terrible.

The signature hack on the system is to reuse sprites mid-frame. That's the "racing the beam": after an object has been drawn, reposition the sprite to draw something else further down on the screen, before the scanline beam gets there.

Pac-Man didn't do that. Instead, it draws only one ghost sprite per frame, and flickers between the four of them every four frames. The flickering and racing-the-beam are opposites, not one causing the other.

Atari's programmers knew how to race the beam for reusing sprites. Air-Sea Battle did it years before Pac-Man. What's different about Pac-Man is that the objects aren't constrained in their movement. They can overlap on the same scanline which makes drawing multiples with a single sprite impossible. The right solution to this and what Ms. Pac did is smart sprite reuse - if they're on the same scanline, flicker temporarily, but then when they move to be separated vertically, race the beam to display both together. This didn't happen for Pac-Man because Atari rushed it to release in too short a timeframe to implement that, and also the code wouldn't have fit into a standard 4k cartridge and would have needed more expensive hardware with bankswitching logic chips. 2600 Pac-Man's terribleness was a business decision, not a technical limitation.

> This didn't happen for Pac-Man because Atari rushed it to release in too short a timeframe to implement that, and also the code wouldn't have fit into a standard 4k cartridge and would have needed more expensive hardware with bankswitching logic chips. 2600 Pac-Man's terribleness was a business decision, not a technical limitation.

There's a lot of myths around 2600 Pac-Man. The game was made in around 5 months, which was a normal amount of dev time for a 2600 game. The ghosts flickering was due to insufficient RAM, not insufficient ROM. Tod Frye, the game's programmer, had a kernel that would reposition the sprites as the screen drew, but it needed additional RAM. Frye really wanted Pac-Man to have a 2-player mode, as the arcade version did and he felt that having a 2-player mode gave the consumer more value. This meant that there wasn't enough RAM to get rid of the flicker, since the game had to keep track of the game state for each player. The 2600 version of Ms. Pac-Man was 1-player only, which is how they avoided the flickering.

Recently they created a good homebrew port, miles ahead of the commercial release.

Reply on news.ycombinator.com