Codes are largely a forgotten element of video gaming. They started out as debug features that didn’t get removed before release, then they became easter eggs to reveal to favored players, ways to dispense unlockables, ways to provide extra difficulty balancing, and even publicity tools, before the age of DLC gave developers a way to profit off of bonus features. Why have players enter up-up-down-down-left-right-left-right when you could just sell them play advantages outright. I’m simplifying the situation a bit, sure, but I’m not simplifying by much.
Codes still exist, once in a while, but it seems like they’ve gone back to being development aids. One of them crept into New Super Mario Bros. Wii, but only becomes usable if the game crashes. The code is: Home, Minus, Plus, Minus, Plus, 1, 2, 1, 2, A. It brings up a scrollable register dump and stack trace, and other assorted information. It doesn’t let you continue playing. For players, it’s just a curiosity, but it’s a thing that is interesting.
Dithering is a method (actually, several methods) of simulating more shades or colors than the hardware is capable of, by producing an array of dots that generally match the colors. One of the qualities of the classic, original Macintosh platform, which used a black-and-white monitor, was the way that it used dithering to give the impression of grayscale shading.
Nowadays most display devices are capable of, in Mac terminology, “millions of colors.” Macs are far from the only devices to have used dithering, but it’s a quality particularly distinctive to them.
There is an excellent article, here, written for developers but clear enough that many non-coders can understand it, that explains how its done, and demonstrates many styles of dithering. Interested readers may also enjoy this article, also on dithering. These pieces, all by themselves, are enough reason to make this post, but they’re not really the things that I want to draw attention to today.
The indie hit Return of the Obra Dinn, from five years ago, is notable because it’s a 3D game, but it uses black-and-white dithering, applied in real time, to do its shading as an aesthetic choice, and the effect is striking. Not just for the dithering, but because the dithering is stable; its dots don’t jump around in a randomish manner, but tends to look like an applied texture, even though it’s generated by an algorithm. You can see for yourself in this trailer:
The cool thing is (and I think it’s linked from one of the articles I presented above), the creator of Return of the Obra Dinn, Lucas Pope, wrote about dithering in a post on TIGsource while the game was in development, and he explains the experiments he ran to get the shading to work and be stable. I recommend graphics programmers to it without hesitation, and others might find it interesting to. I know I do! Have a look!
Sinistar was a game that had quite an impressive sound design. It borrowed a bunch of its sound effects from earlier Williams games, with which it shared common hardware that was originally design for pinball machines. A cockpit version of Sinistar, of which only around 200 units were made, was the first arcade game to have stereo sound. And of course all versions of the game have the Sinistar’s famous digitized threats and taunts.
While Sinistar’s main program source code was found and made available on Github, the source of the code that drove its sound hardware has long been lost. Youtube user SynaMax has done the best he could at recreating that code, and has made a video talking about the process, the sound design of Sinistar and other early Williams games, and even found unused sounds in the code.
Contained within the code is the revelation that the sound chip that drove the rear speakers in the cockpit version ran slightly different code than contained within the main sound ROM. The data from that version of the game was only dumped this year, meaning that the game running in MAME was somewhat incorrect.
Now that the right version of the chip has been dumped, the cockpit version of Sinistar now sounds properly in MAME. Although this does mean that users running up-to-date MAME have to refresh their romset for this version of the game. Such are the tradeoffs of MAME emulation.
Another revelation of the video was that the parametric sound generators used by Williams arcade games from that time often produced interesting noises if it was fed with random data. Sound programmers sought out different sets of numbers to give them, including by asking passers-by for numbers off the top of their heads and garbage values found in RAM when dev systems were powered up, in order to produce strange sound effects.
Devs using more recent parametric generators like bfxr, LabChrip, ChipTone, sfxia, rFXGen, wafxr and jfxr can produce noises by similar means using those programs’ Mutate or Randomize buttons!
I feel like I should warn however, near the end of the video is mention of a bit of drama concerning the MAME developers, in getting code supporting the change integrated into the software. I’m not weighing in on this, not the least reason being I don’t know enough about it. But I feel like you should know it’s coming, ahead of time, before embarking on the 51-minute journey.
A while ago Displaced Gamers, as part of their great Behind The Code series, did a video about how awful NES Strider’s sprite updating was. Arcade Strider was huge hit and outright masterpiece, a great arcade platformer released right before fighting games took over game rooms around the world, but NES Strider was a wretched thing, full of big ideas but with code woefully unable to live up to them. Imagine a puppy trying to do your taxes. It might put up an adorable effort, but it’s just not going to get the job done.
We linked to their last video examining its malformed construction. Well, Strider is the well of crap that keeps on gushing, and so Displaced Gamers has another video on the subject of the flaws in its programming, this time about its player physics. Walking into walls causes Strider Hiryu to shudder in place; jumping beneath a low ceiling causes him to bump his head repeatedly as his jump continues even though there’s no room to ascent; and his infamous “triangle” wall jump is so wonky that it literally requires a frame-perfect input to pull off, and not even the right frame. You have to jump the frame before you contact the wall!
Here is the new video, which explicates the entire cruddy system. It goes into exquisite/excruciating detail, including tracing the code and examining Hiryu’s X and Y coordinates on a frame-by-frame basis. It’s the kind of deep geekery that I just know you love/hate! Enjoy/despair!
It’s just a pointer to a useful site today. OpenGameArt has been around since at least 2009, a place where people can upload game assets they’ve created and make them available to developers, with a variety of licenses. Back in 2013 I used music from it for my own Gamemaker game Octropolis, properly credited of course.
Games made with freely-available resources sometimes get a bad rep, but they can be invaluable for small-team and single developer projects, or anyone trying to get their project off the ground.
I’ve mentioned Kaze Emanuar’s efforts to make the best Mario 64 there can possibly be on its native hardware. He’s compiled it with optimization flags turned on, made its platforming engine much more efficient, and worked hard to minimize cache misses, which was a major source of slowdowns in the game’s code. Under his efforts, he’s gotten the engine running at 60fps (although not yet in a playable version of the original). While these optimizations are not the kind of thing that can keep being found indefinitely, he’s bound to run out of ways to tune up the code, currently he’s still finding new ways to speed it up.
I hope you’re ready for some F-U-N (approximation FUNctions)
He made a Youtube video detailing his most recent optimization find: getting the game’s trigonometric functions executing at their speediest. What is interesting is that the Mario 64 code already uses a couple of tricks to get sine and cosine results in a rapid manner: the game only uses 4096 discrete angles of movement direction, and contains a lookup table that covers each of those angles. But it turns out that this optimization is actually a mis-optimization, because the RAM bus hits incurred to read the values into the cache are actually more expensive than just figuring out the values in code on the N64’s hardware!
The video starts out decently comprehensible, but eventually descends into the process of figuring out sine and cosine on the fly, and the virtues of the various ways this can be done, so you can’t be faulted for bailing before the end, possibly at the moment the dreaded words “Taylor series” are mentioned. But it’s a fairly interesting watch until then!
Helper Wesley on Youtube is making a Binding Of Isaac-style randomized twin stick shooter called Spent Shells, and published it on Newgrounds. It’s on itch.io too. It got about 35,000 plays and an award from the site, which is nice. It also got ripped off and put on a bunch of other sites, which wasn’t. But things seem to be going well with it.
Wesley put up a video with his experiences with its popularity and his attempts to monetize it. It’s only ten minutes, and it’s got a lot of useful information for things to do that might help out your own project, if that’s the kind of thing you do, or just an interesting look at an experience most of us won’t even have.
Turbo Rascal, more fully known as “Turbo Rascal Syntax Error” or TRSE, is a multiplatform game and demo development system, including a compiler, afull IDE and some miscellaneous utilities like an image editor. It’s based on Pascal, which might be annoying to people who have the conventions of C burnt into their brainmeat, but is easier on newbies on the whole, since its language idioms tend to be more readable for intent, and it doesn’t include structures like the ternary operator: (a ==0) ? isequal() : isnotequal();
While it supports a lot of different classic computing devices, TRSE’s “native” platforms, those it has the most support for, are the 8-bit Commodore machines. Using it, you can pretty rapidly put together a program to display an image on the C64’s hi-res screen:
It comes with a lot of example projects too, including a number of technically proficient demos that show off its capabilities. After you install a C64 emulator (VICE is recommended), the following can get up and running in less than a minute:
Xevious was modestly successful in the US, where it was produced by Atari, but it Japan it did amazing numbers. Jeremy Parish (in his NES Works and related series) has mentioned several times that it was a vastly influential game in Japan, inspiring a whole generation of designers, and a whole bunch of clones and similar games. Its US release was around the time of the arcade crash, which was mostly an American thing. If it hadn’t had happened, maybe now we’d think about Xevious the way we consider Pac-Man.
The team behind Xevious
Xevious basically invented the vertical scrolling shooter where your ship has free movement of the screen. It also included a Bomb button to attack objects on the ground, displayed on the game’s background layer. It was a concept that would later be iterated upon in Konami’s Twinbee games.
Revealed in the article is an interesting fact. The scrolling background is stored in ROM as a huge 1024×2048 bitmapped image. That’s much wider than the screen is though. What the game does is send the player into a vertical portion of it 224 pixels wide.
When the player reaches the top, they wrap around to the bottom of another vertical stripe of the game world. In a complete loop, the player will travel from the bottom to the top 16 times. You can tell when you’re about to start another loop because the background will reach a place with trees all the way across!
You always start off a life in a tree-filled area because it begins you at the bottom of a stripe; each vertical pass over the map functions as a checkpoint. The stripes overlap somewhat, so you sometimes pass over an area you’ve seen before but offset by a bit.
For more facts on Xevious and its development, be sure to click through to the article!
Andred Braybrook is a legendary computer game dev from the Commodore 64 age, and before and after. In addition to the classic C64 games Uridium and Paradroid, which perform feats of scrolling that machine are really not designed for, he went on to many several other games, including the excellent computer ports of Taito’s sequel to Bubble Bobble, Rainbow Islands.
(Although Braybrook mentions that Taito hadn’t told him about the three secret islands that can appear at the end, so they got left out. They didn’t know about them either!)
Image from Braybrook’s blog
He has a blog post that details many aspects of he and his co-workers’ process back then that is fascinating to anyone with knowledge of these platforms, and even someone who doesn’t. Thanks to @acb@mastodon.social for the link!
The Legend of Zelda: Breath of the Wild is a gigantic game, and where content proliferates, so too do bugs. Many of these bugs are highly entertaining (my favorite is the bullet time bounce), but there are some that are just head-scratching, leaving one to wonder why does this happen? That the occur pulls back the curtain on the many technically complex things a big game like BotW does behind the scenes to realize its world, for, every step of a process that a system must go through is one more opportunity for something to go wrong.
Youtuber Jasper has made a 35 minute video about why, if Link stands in a specific spot in BotW, inside the broken corner of a stone wall, the cel shading usually applied to his model goes away, and he appears with normal light shading. In the way of Youtubers, the explanation is contained within a 35-minute discursive video that goes into the history of game lighting, why some older 3D games have graphics that have aged well while others don’t, the basics of cel shading, and still other topics. Here is that video, embedded:
The whole video is pretty interesting, and if you have the time and interest you should watch the whole thing. However, in the event that this is all tl;dw, allow me to summarize.
Because Breath of the Wild is both a huge game and has a dynamic world, baking lighting in into textures would consume way too much storage and memory, so lighting has to be done dynamically.
As an optimization measure, the more complex steps of cel shading are deferred to later in each frame’s rendering. The main rendering is done, then the cel shading is applied afterward, when the visibility of the area has been determined, so this effort-expensive process is only done for visible pixels.
One of the deferred steps of rendering marks which of nine different kinds of material will be applied to each pixel. Terrain in BotW is not cel shaded, while characters link Link are, so they have different types of material that determine whether that shading is applied to them.
In the location where Link’s cel shading disappears, there is a decal applied to the crumbling bridge that erroneously extends over the corner, and overwrites Link’s character material type with the terrain material, causing the cel shading not to be applied to him.
