Original post: https://www.reddit.com/r/pinball/comments/1lwx8hu/pinball_2000_development_lore_part_3/
These are my experiences as part of the Pinball 2000 team. Feel free to ask questions. I’ll gather up multiple answers into one comment like I did with the initial post. Now, without further ado…
Part 3 – Satisfying artists while still making smart compromises
Pinball machines are creative works, made by a team with different specialties. Some roles are more technical and some are more artistic, but it’s good for team members to have mutual understanding and mutual respect. Even though I wasn’t on a game team I felt it was very important to get to know the artists especially since most of them were new. We had Adam and Scott, both of whom had made dot matrix art for WPC, so that was where I started.
15 bit colour (as described in part 2) was very helpful for their work, so that was good. We needed a way for the art to have a pixel be transparent and there were two approaches. We could’ve used a mask (whether the unused bit, or a separate image entirely) or we could use one specific colour as a ‘key colour’. Pixels of that one colour are treated as transparent when drawing the image. I don’t remember who drove this conversation, but it was easy for us to choose that second option and to use pure magenta (so 31 red, 0 green, 31 blue) as the key colour, because that’s such a harsh colour and the artists didn’t think they’d use it much anyway. They also knew that even if they did want to use it, they could use an almost-identical colour (e.g. 31 red, 1 green, 31 blue) and it would look fine. The advantage for me of using a key colour is all the existing software tools would work as-is and it would be easy for programmers or artists to understand what happened. If we had used the 16th bit you’d have an opaque and a transparent version of every colour value and it would’ve been hard to visually tell what was going on with the source art when things looked wrong on the game screen. If we’d made a separate image for the mask that would’ve made things harder for the artists because they’d have to update the art itself and its mask together. We’d also have two chunks of data in ROM that needed to be combined in RAM in order to update the display. Modern video hardware works so differently that these aren’t meaningful concerns any more, but they really mattered in 1998!
I think it was Adam who really wanted alpha-blending, which the video hardware didn’t support natively. I could’ve done this purely in software, but that would’ve been very slow. I had to explain the basics of why and I also offered a compromise, which was that you could stipple transparent pixels with opaque ones by making alternate pixels magenta. Think of white squares vs black squares on a chessboard. It’s not great, but it’s better than nothing.
Alpha blending is a sort of translucency. Rather than having a pixel be opaque or transparent, it lets you combine the pixel you’re drawing with whatever pixel is already in place underneath it, sort of how sunglasses stop some of the light coming through but not all of it. For example, blending pure blue and pure green at 50% alpha will give you a medium cyan tone like teal. To do this you need to multiply one pixel by the alpha, the other pixel by 100% minus the alpha, and add the results together. So pure blue becomes 50% blue, pure green becomes 50% green and when you add the two together you get 50% cyan. You have to do this separately for each colour channel.
That works out to 6 multiplies, 6 divides and 3 additions as well as the work to separate and recombine the colours. The CPU we were using was not optimised for this sort of math, so it would’ve taken probably 20 times longer per pixel, plus the alpha values would’ve had to be stored separately. I sympathised with the artists a lot, but I wasn’t willing to do this work. Artists are passionate about making everything as beautiful as possible, so they would’ve used it in all their art and the performance would’ve been really slow. It’s unfair to expect artists to limit themselves to satisfy unintuitive, highly technical constraints when they could have a clear rule. If we’d upgraded to video hardware that could do this natively, I would’ve made it first on my list of updates.
Since the artists had been part of the decision making process and I could show I was considering their needs, the lack of alpha blending didn’t become a contentious issue. This really helped because the next compromise would be a really, really big one. This was about image compression.
There are lots of ways to compress images so they take less storage space. There’s no single optimal technique because there are always trade-offs. I knew we’d need something that was efficient for storage and fast to decompress. Compression could be slow because it was done offline and only needed to happen once, but decompression would happen whenever we wanted to have the image in RAM. I was worried about this and I’m sure Tom and I would’ve talked about it but I didn’t have a clear solution. We were lucky because one of the programmers working on console videogames in the San Diego office, Mark, was a big pinball fan and he showed us a really good way to solve our problem. He’d had very similar requirements for making a console port of Mortal Kombat so he could fit the huge quantities of animation into a game cartridge.
The compression involved finding repeated pairs of pixels in an image and building a dictionary of the most common colour pairs. Then, instead of listing each pixel individually, it could say to repeat a dictionary entry (so a specific pair of colours) however many times; this is a version of run length encoding (RLE). This was easy to add to the image processing tools, and the decompression code was fast. However, in order to be effective it needed the source image to use a limited number of individual colours so there’d be plenty of instances of a smaller number of colour pairs. Mark had made two versions of this, one that allowed 64 unique colours and a 64 entry dictionary, and another that only allowed 32 colours but had a 128 entry dictionary. The latter version was great for things like icons and fonts where they’d only use a few colours anyway.
The artists were very unhappy with this idea whenever I talked it over with them. I’d given them the ability to make lovely art with colour gradients and subtle shading and now I wanted them to limit that by making each image only have a fraction of all those possible colours! We talked it over repeatedly, including Tom getting involved, but there wasn’t an agreement between us all. The thing that settled the matter was that when Mark came to Chicago I asked him to talk to the artists directly without me or other pinball programmers present. I don’t know what he said to them, but he convinced them that this was a good solution and they’d still get to make beautiful things and the games could have lots of nice art stored in the 60MB of ROM. If I hadn’t worked to gain the artists’ trust in the beginning I’m not sure even he could’ve convinced them. By the way, Mark has long worked for Stern Pinball (and is the most senior programmer in the company, if I understand his job title correctly – if not I expect he’ll appear to set the record straight).
It’s important to make smart technical decisions, but it’s also important to foster mutual respect. A tight-knit team with fewer resources will usually do a much better job than a fractious team with plenty of powerful features. This way of thinking came up over and over for Pinball 2000 whether just among programmers, or designers, or engineers or multiple types of colleagues. We all knew it was do or die for pinball at Williams and we all wanted to succeed and that helped us coalesce around a single vision.
Recent Comments