Tag: graphics

On PETSCII

We’ve brought up a couple of examples of Commodore PET software lately, which as I keep saying, is interesting because the PET has no way of doing bitmapped graphics, sprites, or even definable characters. Its characters are locked in ROM and cannot be changed. So, it includes a set of multi-purpose characters that was used throughout all the Commodore 8-bit line, even as late as the C64 and C128, which having definable graphics didn’t need these kinds of generic graphics characters, but they were still useful for people who didn’t want to create their own graphics.

The PETSCII characters, as used on the Commodore 64 (image, with some editing, from Wikipedia). The graphics set also includes reverse-video versions of each character.

Back on my Commodore coding days I became very familiar with these characters. I think they’re much more universally-applicable for graphic use than the IBM equivalent, the famous Code Page 437, although that’s mostly because PETSCII doesn’t bother defining supporting so many languages. Code Page 437 also uses a lot of its space for single and double-line versions of box-drawing characters, although on the other hand it doesn’t waste characters defining reverse-video versions of every glyph.

PETSCII has:

  • A space and reversed space, of course.
  • Line drawing characters for boxes of course: vertical and horizontal lines, corners, and three- and four-way intersections. There are also curved versions of the corners.
  • More line-drawing characters for borders.
  • Still more horizontal and vertical lines, at each pixel position within their box.
  • With the reverse-video versions, enough characters to effectively do a 80×50 pixel display, as if it had a super low-res mode.
  • Different thicknesses of horizontal and vertical lines too.
  • Diagonal lines, and a big ‘X’. Note that on the PET and Vic-20 these lines were all one pixel wide, but on later computers with both better resolution and color graphics they were made thicker, which means diagonal lines have “notches” between character cells.
  • Other miscellaneous symbols: playing card symbols, filled and hollow balls, and some checkerboards for shading. On the PET and Vic, the shading characters were finer, while on the other 8-bit computers they were made of 2×2 boxes.

There are resources that let you use PETSCII to create old-school computer art, like this PETSCII editor, Petmate and Playscii, and for a bunch of examples of what you can do with it you can browse through the Twitter account PETSCIIBots. And this blog post from 2016 both makes the case for PETSCII as a medium for art and provides some great examples of it.

Some robots from PETSCIIBots

Digital Antiquarian on 3D Graphics History

That excellent blog The Digital Antiquarian has three posts so far in a history of 3D graphics, starting from the likes of Doom and Quake and so far going as far as 3DFX.

Part 1: Three Dimensions In Software (Or, Quake And Its Discontents):

Quake (All images from The Digital Antiquarian)

“By the middle years of the decade, with the limitations of working with canned video clips becoming all too plain, interactive movies were beginning to look like a severe case of the emperor’s new clothes. The games industry therefore shifted its hopeful gaze to another approach, one that would prove a much more lasting transformation in the way games were made. This 3D Revolution did have one point of similarity with the mooted and then abandoned meeting of Silicon Valley and Hollywood: it too was driven by algorithms, implemented first in software and then in hardware.

It was different, however, in that the entire industry looked to one man to lead it into its algorithmic 3D future. That man’s name was John Carmack.”

Part 2: Three Dimensions In Hardware:

Pro Graphics 1024

“Born in Salt Lake City in 1924, (Dave) Evans was a physicist by training and an electrical engineer by inclination, who found his way to the highest rungs of computing research by way of the aviation industry. By the early 1960s, he was at the University of California, Berkeley, where he did important work in the field of time-sharing, taking the first step toward the democratization of computing by making it possible for multiple people to use one of the ultra-expensive big computers of the day at the same time, each of them accessing it through a separate dumb terminal. During this same period, Evans befriended one Ivan Sutherland, who deserves perhaps more than any other person the title of Father of Computer Graphics as we know them today.”

Part 3: Software Meets Hardware:

The custom version of Quake made for Vérité

“Among these, of course, was the tardy 3Dfx. The first Voodoo cards appeared late, seemingly hopelessly so: well into the fall of 1996. Nor did they have the prestige and distribution muscle of a partner like Creative Labs behind them: the first two Voodoo boards rather came from smaller firms by the names of Diamond and Orchid. They sold for $300, putting them well up at the pricey end of the market —  and, unlike all of the competition’s cards, these required you to have another, 2D-graphics card in your computer as well. For all of these reasons, they seemed easy enough to dismiss as overpriced white elephants at first blush. But that impression lasted only until you got a look at them in action. The Voodoo cards came complete with a list of features that none of the competition could come close to matching in the aggregate: bilinear filtering, trilinear MIP-mapping, alpha blending, fog effects, accelerated light sources. If you don’t know what those terms mean, rest assured that they made games look better and play faster than anything else on the market. This was amply demonstrated by those first Voodoo boards’ pack-in title, an otherwise rather undistinguished, typical-of-its-time shooter called Hellbender. In its new incarnation, it suddenly looked stunning.”

The Next Generation in Graphics, Part 1: Three Dimensions in Software (or, Quake and Its Discontents)

Roguelike Celebration: Joel Ryan on Creating the Sil-Q Tileset

Sil-Q is an Angband variant. Joel Ryan, aka MicroChasm, made its tileset which shows a lot of care in its creation. Sil-Q’s tiles are modular, so humanoid monsters can hold weapons, and also have strong silhouettes to aid recognition. It’s full of the kinds of concerns pixel artists have to worry about!

Silhouettes of various monsters in Sil-Q
As a bonus, the talk provides this lineage of Sil-Q!

Pixel Art Manipulation Tools

Tiled is a popular open-source tool for tilemap construction

Popular and prolific game asset creator Kenney has a page up at Github that links to some of his favorite tools for manipulating pixel art, such as creating sprite sheets and extracting images out of them. It’s got a lot of useful info! If you have an interest in this style of art, especially making games with it, these programs are worth having in your toolbox.

Kenney: Manipulating pre-made game assets

PS1 Rendering Quirks

via @doc on Twitter. PikumaLondon tweeted out a thread (unrolled) explaining, in general, how the original PlayStation rendered graphics, and the source of its distinctive graphic artifacts, specifically texture warping, pixelated textures, and jittery polygons. The Nintendo 64 didn’t have these problems, but also couldn’t draw as many polygons each frame.

The thread also links to developer David Colson’s efforts to create a PS1-style 3D fantasy console. I’m sure this isn’t interesting to everyone, but worry not, this blog isn’t going to become entirely low-level hardware rendering geekery. At least, not yet.

The Hidden Structure of the Overworld of Link’s Awakening

pmorinerie (on Mastodon @pmorinerie@mastodon.xyz) has been working on a full disassembly of the fourth Legend of Zelda game, Link’s Awakening on the Game Boy, and has a series of articles they’ve written about interesting technical aspects they’ve found.

One of their discoveries is of a hidden structure to the overworld of that game. Their discussion of this is fascinating, and should be referred to if you have an interest in such things. I will give a broad summary here.

The Game Boy was not given much VRAM for storing graphics. To avoid bus conflicts, the CPU that runs the system only has access to VRAM, to store new background tile information, either during VBLANK, a specific time each frame when the PPU circuitry isn’t accessing memory, or by blanking the screen entirely, which is only really feasible during major transitions, like through a door or into a hole. So, the system is limited in how quickly it can store new tiles during play.

Link’s Awakening stores two kinds of tiles in its VRAM. Most of them are from a set that’s used throughout the overworld, but a small number are overwritten, used for different purposes as Link explores the landscape. The overworld is separated into 2×2 blocks, and each can have its own set of these customized tiles.

There is a problem with this setup, however. When Link changes screens, like in the original Legend of Zelda and A Link to the Past, the screen transition scrolls smoothly between the areas. During the scroll, briefly, it’s possible for elements from two different screens to be displayed at once. How does the program handle situations where the custom tiles have two different definitions between screens?

The answer is that the overworld is cleverly designed so that there aren’t adjacent screens with walkable passages between them that use different sets of custom tiles. There are screens in the game that only use tiles from the main overworld set, and all of the places with passages between the screens with custom tiles have one of them, as a kind of memory airlock, to prevent glitches during transitions. It’s pretty clever.

If this is interesting to you, I encourage you to read the whole article, especially for the exceptional cases where the system breaks down and they had to find other ways to keep the screen from glitching.