Slashdot Mirror

If you like this kind of investigation, you might be interested in hacks of the Atari 2600 version of Pac-Man. The port from the arcade was notoriously bad, because the hardware of the Atari basically didn't map well onto the graphics needed for the game. As a result, everything is basically wrong: the pills are fat dashes, the elegant outline graphics of the original are blocky opaque colors, etc. But worst of all, since the Atari's two sprite registers are used to draw both Pac-Man and the ghosts, whenever there are more than 2 ghosts+PacMan on a horizonal scanline, they start flickering because the porters resorted to the horrible hack of round-robin rotating which sprites got to be drawn in the 2 sprite registers. (This looks slightly less horrible on a CRT with phosphor decay, but it still looks bad.) Anyway, if you want more on the details of why this port sucked, and how it can be traced to hardware mismatches, it's covered in detail in ch. 4 of the book Racing the Beam .

But on to the hacks: Rob Kudla discussed and did some work towards a better Atari 2600 port in the late 1990s, and there are now a number of attempts, though many of them do cheat by doing things like using an 8K ROM rather than the original 4K.

The Atari Flashback isn't based on any Atari hardware, but "Famiclone" technology (most similar to the NES) like all those "system in a controller" devices. In fact, just looking at the screenshots , I can't even find one that it'd be possible to render on the 2600 (having done some coding on it myself.) They all have either too many pixels or too many colors per scanline, though obviosuly not too many for NES hardware.

For me, this contest might have actually been more challenging than writing a 2600 game in 24 hours, since I know the 2600 but I'm not familiar with coding for the NES nor with the development tools they were using (which was apparently the Windows program "Game Maker" with a limited set of sound effects and limitations on resolution and colors.)

To be fair, though, the game that won ("Ninja Garden") was the closest of all the games to looking like an actual 2600 game.

There are lots of choices, really. I wrote a perl script (using Image::Magick) about 5 years ago that did the same thing as this, and the awesome GQView image manager has had visual image matching for nearly as long. On the Windows side, I'm pretty sure ThumbsPlus has a feature like that, and I'm surprised they didn't build it into XP since they were supposed to be all digital-photo-friendly.

Some of us who use and develop Gambas agree with you. I began work on an MDI IDE for Gambas a year and a half ago, and released actual working code, but the language was such a moving target at that time (version 0.57) that I had to abandon it. I hope to produce one for Gambas 1.0 in the near future, and Benoit plans to add MDI functionality to the IDE in the development series for 2.0.

About 20 versions ago I made an unofficial MDI version of the Gambas interface, and a new official MDI version is planned for the 1.1 series (like the old kernel numbering scheme, 1.odd will be development and 1.even will be stable.)

For what it's worth, it didn't take much coding at all (though I didn't do docking or any of that cool stuff), and I'm looking forward to using an MDI version again.

Just for posterity, here is my MDI hack. It long since stopped working with current Gambas releases due to changes in the rest of the IDE.

more information from the author of this hack: here.

Probably to protect the rover in case of this scenario .