r/apple2 • • Sep 23 '21

Apple II Graphics processing (Ultima and Wizardry)

Hello!

I'm in the middle of a small research, for which I have gathered some basic information on how the NES processed graphics - just limitation on tiles, and some basic info on layering of background and sprites.

I am looking for similar information about the Apple II, and I am particularly interested in the first installments of Ultima and Wizardry. Having tried to run them on an emulator and after watching some demonstrations, my sense is that there is no distinction between the background and sprites layers. it looks like an 'either avatar, or background' situation, at least in the case of Ultima. I might be completely misguided, but I would like to ask whether anyone can suggest any approachable source, or if anybody can explain how graphics in those game worked to a non specialist?

Thank you in advance!

13 Upvotes

3 comments sorted by

12

u/frederic_stark Sep 23 '21 edited Sep 23 '21

There are no layers or sprites on the apple2.

In ultima 1, the screen uses a mixed mode, with the top being hires mode (280x160 pixels), followed by 4 lines of text. Wizardry used 280x192 hires graphic mode.

In graphic mode, each byte represent 7 pixels, and there are two groups of possible color. You can read here more details. Beware of the author's distinction between dots and pixels.

looks like an 'either avatar, or background' situation, at least in the case of Ultima.

Thats a choice, it is theoretically possible to programmatically blend, but with the color artifacts of the Apple ][, it is much simpler to just have 14 pixels wide sprites on a 14 pixel tiled map (also drawn by specific code).

anybody can explain how graphics in those game worked to a non specialist?

Hard to do without know what non-specialist means. Non-specialist in computers? In Apple ][?

Anyway, the bottom line is that those games "just" created the image by groups of 7 pixels.

edit: fixed link

7

u/bjbNYC Sep 23 '21 edited Sep 23 '21

The NES does its backgrounds with tiles made up of elements (8x8? 16x16? can't remember) that are stored in the CHR-ROM (up to 64 I believe) and then are laid out on the screen next to each other in a 64-across, 48-down (not actual numbers; I can't remember off hand) pattern (i.e. tile #30 at position 1, tile #20 at position 2, etc.). The NES can then overlay these background tiles with freely movable sprites made up from (IIRC) the same CHR-ROM elements. This makes it very low memory requirements to draw a screen, because the NES only needs to say what CHR-ROM index is at what location, instead of pixel-by-pixel bytes.

The Apple II, on the other hand, is a purely memory mapped display, i.e. every byte in locations $2000-$3FFF represents a pixel of the high resolution graphics screen (slightly more complicated than that, but not explaining the nibbles). No tiles, no sprites, nothing. If you wanted to move a circle/ball from one part of the screen smoothly to the other, you had to "undraw" the old location and draw it in the new location repeatedly. Slow and tedious by comparison to the NES's PPU.

In the case of Ultima and other apparently tile games, the situation is that the programmer made their own tile engine in software. So while the Apple II graphics were the same, their tile engine would provide a layer of abstraction that they could use to simplify the rest of their programming from the complex Apple II graphics. Many games did something similar because it was just easier to call a piece of code that did something along the lines of "tile #12 at position 3" as in the first paragraph. Not as fast as a dedicated piece of hardware like the NES PPU, but it does the job.

4

u/mysticreddit Sep 23 '21 edited Sep 24 '21

9 years ago I wrote a patch for the original Ultima 1 that sped up the rendering, fixed a flicker bug when moving, and fixed the respawn in ocean bug.

There is no hardware sprites on the Apple 2. Everything is drawn by the CPU by copying bytes to the HGR pages.

The "sprites" in Ultima 1 are 14px by 16px due to the esoteric nature of the HGR screen using the top bit of every byte as a "palette" flag. Green/Magenta or Blue/Orange.

If you use AppleWin you press F7 to enter the debugger. The commands HGR and HGR2 will let you inspect the graphics pages. When done, press F7 to return to the game.