[Click for all books]
Armchair ArcadePromote Your Page Too
I believe the C-64 version suffered the same graphics problems as the Atari 8-bit version (which I had), and it was largely due to the way the C64/Atari handled colors in high resolution mode (320x200). I believe this is a case of "conversionitis," where the ported version actually suffered compared to the Apple II version.
You are certainly right about the "conversionitis" as the Atari and C64 ports are criminally cheap - they didn't even attempt to use the potential of these machines. One should note, though, that Bill Budge was an ace programmer on the Apple II and in part unlocked the potential of this machine for other game programmers! I don't know who did the ports but they apparently weren't in the same league.
The Atari had higher resolution (as did the C64) than the Apple II, but the Apple II graphics system allowed for an odd mix of "hi-res" and "medium res" on the same screen. On the Apple II, if you wanted to draw a white line, it plotted the line in hi-res on the screen, but if you wanted to plot a green line on the same screen, it plotted the line in "medium res," reducing the resolution of the line to produce the color. This allowed for more colors on the screen
I'd like to point out some things I described about the Apple II graphics earlier (see my lenghty posts in this entry: http://www.armchairarcade.com/neo/node/1764) and add a few "bits" about the newer systems.
First of all the color generation of the Atari and the C64 are fundamentally different than the method used by the Apple II series (minus the IIgs) - they actually *can* produce colors, whereas the NTSC Apple II's only produces timed white pixels to generate NTSC colors via its composite video output - by "artifacting" (a PAL Apple II also outputs real colors but we ignore that here as the technical details of the frame buffer remain identical). A pixel that is sent to the screen is always white! The position of the pixel and if it is surrounded by other pixels decide if a color other than white is generated (by the display - not the Apple itself).
When two (white) pixels are next to each other they show up as the color white on screen. When a pixel is surrounded (left and right) by a "black" pixel (a "0 bit") then the position (=timing) decides which of the real colors (green, violet, blue & orange) is used in the hires mode. This also results in strangely colored text in hi-res mode like the Ultima I title screen, when the letters have one pixel thick parts. See: http://armchairarcade.com/neo/node/1956
The resolution of the Apple is 280 pixels and not 320 like with the Atari and C64 because it reserves one bit of the 40 byte (= 40 bits = 40 pixels) for the so-called "color bit" which shifts the timing of the displayed pixels by a half-pixel and that results in shifted frequencies and therefore different colors.
From a technical standpoint this complicated scheme is very clever: Instead of four colors you can generate an additional four colors with it (two are identical to the first four, though: black and white) so you get a grand total of six different colors. The hardware design for this functionality is pretty simple but it usually comes with an increase in the program's complexity.
without much work from the artist,
Objection, your honor! ;-) It requires much more work as the above described color-bit produces a phenomenon called "color clash". This means that you can't use colors of the "first palette" (color-bit = 0) together with the "second palette" (color-bit = 1). In other words: A frame buffer byte in this Apple II hi-res mode is only able to display four out of the six different colors.
This results in wrong colors when you try to mix them - for example by drawing an orange line through a rectangle filled with green color. The orange line will look like a staircase with thick steps in this case - quite ugly. Therefore one has to carefully design the colors you want to appear on screen and tile-based games like the Ultima series were a logical consquence.
and without really sacrificing resolution if you were a careful artist.
That's right but the "high resolution" of 280 pixels per line can only be white pixels and they have to be next to each other. A good example is the hand cursor in PCS or the population in the Ultima games which are mostly white in color.
The Atari could only produce one color in hi-res unless you "cheated" by using a technique called "artifacting," which utilized a quirk in the way TV sets plotted pixels. Since "hi-res" mode was actually higher resolution than the analog TV signal, an individual "pixel" would display either green or brownish-red, not white, unless two dots were placed together. By cleverly utilizing "artifacting," you could cheat the system and display more colors than the computer intended. I believe the C64 system worked similarly in Hi-res mode, and many games utilized "artifacting." That's probably the reason of the "muddy brown" color of the tables. Of course, there was the "color cell" system with the C64 that could get around some of these limitations, but it was a very technical way to produce color and would not have worked with PCS, due to that "game's" flexibility and ease of use.
Both Atari and C64 are much more advanced compared to the Apple II because of their custom chips (and their later market launches) and support several modes of which two are interesting in this case (I simplify a bit here):
Atari: 320x192 with one color in two shades
C64: 320x200 with two colors in each 40x25 cell of 8x8 pixels (because of 1KB "Color RAM")
Both modes can use artifacting but the Atari has a) more need for it in this mode (it has no "Color RAM") and b) this only works reliably with NTSC and not PAL displays. This results in poor displays in PAL countries with the Atari versions of PCS and Ultima IV, for example.
If you want a higher color granulation (that is more colors per pixel field) then you have to use this mode:
Atari: 160x192 with four colors controlled by color registers
C64: 160x200 with four colors controlled by color registers and more if you use the Color RAM (8x8 pixel grid)
The advantage of this mode are that there is no color clash between the four main colors on both machines - resulting in a "clean" display and that you can change a single color on the screen with a simple manipulation of the color register.
The disadvantage is that you don't have the high white resolution of the Apple, though the C64 apparently allows for mixing graphics modes on a cell basis (if I understand that correctly), though it isn't used in the PCS port.
Now which modes are used by the PCS ports:
Atari: 320x192 with two shades of grey (white and black) resulting in color artifacting
C64: 160x200 with four colors and no use of the Color RAM, which you described above
Therefore the "muddy brown" was an intentional choice of the C64 port programmer and may actually resemble the artifacted screen of the Atari port. One can try the different combinations of NTSC/PAL video modes and artifacting settings due to different video chips (CTIA and GTIA) of the Atari in the emulator Atari800Win.
IMHO both conversions could've been better:
The Atari should've used it's 160x192 mode and the hand-cursor should be made with Player-Missile-Graphics. It would loose a bit of the resolution (not that important on the TV sets of that age) but it could've had a fifth color making it easier to discern than the EOR-ed shape of the hand it now has.
The C64 is in desperate need of better colors as pinball tables usually aren't black, muddy brown, dark blue and white (very easy to do) and also a sprite could've been used for the cursor.
Thus, both the Atari and C-64 version probably suffered from a lack of colors compared to the Apple II version,
Very much so, as the Atari doesn't have the half-pixel shifting of the Apple and therefore less colors with artifacting. The C64 on the other hand also only uses four colors because it doesn't use its Color RAM. One *could've* used it, though, and though the added code complexity would've used a bit more RAM the argument isn't valid as it *has* 16K more RAM than the 48K Apple II (not even taking into account that the Apple loses a few K for its DOS while the C64 doesn't).
even though both systems had ways to get around color limitations through technical means.
Both systems allow for more colors with sprites (Atari: "Player/Missile Graphics") and horizontal interrupts (Atari: "Display List Interrupts") which modify the color registers. All of them have their limitations though and a game which uses the whole area of the frame buffer more or less equally is not exactly an ideal situation.
Being a straight port of the Apple II version, the Atari version even had all the sounds coming from the computer's internal speaker, rather than through the TV's speaker! While this was normal for the Apple II system, on the Atari, it came across as low-tech and clunky.
Such piss-poor conversions are really a shame. While I can (barely) understand why the artifacting was chosen for the Atari the ignorance of its sound capabilities is proof for incompetence (or will to cheat the customers out of their money). As the Atari port is copyrighted 1983 there really is no excuse for this as the internals of this machine were publicly known for roughly two years and lots of competent Apple machine language programmers fluctuated to the Atari - praising its better architecture (and many fluctuating later to the C64 because of its bigger market share ;-)
More information about formatting options
All editorial content © 2003 - 2013 Armchair Arcade, Inc., an Armchair Creative Services, L.L.C., property. All rights reserved unless otherwise indicated. All trademarks and copyrights are retained by their respective owners. No content is to be removed or reused from the Armchair Arcade Website for commercial purposes without explicit permission from the principal Armchair Arcade staff, or the original trademark or copyright holders. Armchair Arcade, Inc., is not responsible for the content of any external sources or links. Further, endorsement of any external sources or links is neither implied nor suggested.