Another Youtube video? Yeah I know. This one explains how gravity works in Super Mario Galaxy. It’s 29 minutes long. The basic gist is, there are eight kinds of invisible gravity field objects, based off of simple shapes, in the game, which are used in concert to create the various orientations that Mario switches to as he moves around: Parallel, Sphere, Cube, Disk, Torus, Cylinder, Wedge, Wire (basically an arbitrary path in space), and Cone, which is only used in two places.
An interesting fact from near the end of the video: gravity affects Mario’s shadow! Shadows point towards where Mario will fall, not according to how light strikes him, to give players a sense of where he is spatially in 3D space.
The Youtube channel Retro Game Mechanics has done a series of three videos on glitches in Super Mario Bros. One involves using the NES game Tennis, which has a certain property of its code that allows you to load all kinds of funky levels in SMB.
They’re all interesting, but the one that floats my particular boat is the third, which turns into a deep dive in the compressed manner that Super Mario Bros. stores its levels in ROM, and uses to draw them during play in real time.
Honestly, I could devote a post to every Roguelike Celebration talk. I’ve been limiting myself to just one such post a week, on Saturdays. This one, a short sixteen minutes talk about terrain generation, is for the developers out there.
Constraint-based generation, also known as “wave function collapse,” is a system where, as objects are placed randomly during generation, the generator “solves” the world around them, placing later terrain as is necessitated by prior terrain. If the generator reaches a contradiction, a situation where there is no viable terrain that can be placed, it undoes the contradictory placement and continues from there.
It’s a technique that’s fairly popular in procedural generation circles, and among other games is used in Caves of Qud. It’s also fun to watch it work!
Zoid Kirsh on Twitter (while Elon Musk hasn’t completely wrecked it yet) tweeted about how Metroid Prime’s save system works. Metroid Prime save files are less than 60 bytes long! A single Gamecube memory card block is eight kilobytes, so it’s a bit overkill, but it’s still nice when a developer is frugal!
Image, of Metroid Prime’s inventory screen, from Mobygames.
The way they explain it is that the game has a number of “world layers” which determine what is spawned in each area when it’s loaded. Which layer is active when a room is loaded is determined by a single bit in the save. That, plus some basic stats like health and ammo, and the record of object scans, all take up very little memory when bit-packed.
If Metroid Prime’s save file were 59 bytes long, that would mean it had 472 bits to work with. The passwords used by the original Metroid only stored 144 bits of data!
The title refers to the original NES TMNT, not the arcade version or the NES game based on it. This is the version that Konami released under their Ultra label. It sold well (real well!) but is widely considered an inferior game for a number of reasons. Those reasons are the subject of these three videos, from Youtube channel Displaced Gamers. I recommend them, even if I think every place they say gamer it would be more proper to say player.
The first video:
In a long and difficult game, one of the hardest sections comes relatively early. The only swimming section in the entire game, players must maneuver their supposedly-aquatic surrogates through a difficult course that has imprecise movement, water currents, high damage, instant kill hazards, a strict time limit, and, as the video shows, buggy implementation. Many players in the NES era gave up at this point, which is rather a shame considering it’s only at the end of level two. This video examines the code and demonstrates why it’s so challenging, and how it could be made fairer.
The second video:
TMNT has notoriously floaty jumps, a low frame rate, and a fairly weird implementation of gravity. Any platform game that allows players to adjust their jump height according to how long the hold down the jump button is fudging its physics behind the scenes, but TMNT does it rather poorly.
The third video:
Displaced Gamers examines additional problems with the game’s timing, particular with that of its input reading and attack animation. Like the other two videos, they suggest code changes (sometimes in the form of Game Genie codes) that fix the problem, if you happen to have a fondness for 6502 assembly. (I do!)
If you’d like to try NES Teenage Mutant Turtles, it’s included in the “Cowabunga Collection” that was released for Switch, Xbox X/S and Playstations 4 and 5. Fortunately, it also includes twelve much more playable titles.
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!
From Roguelike Celebration 2022, Reed Lockwood’s talk on trap design in roguelikes. Traps are an essential part of a D&D-style dungeon exploration sim, but are very easy to get wrong, either by making them too strong or, conversely, too weak. Some interesting ideas here!
Street Fighter II has some really complex spritework! Its characters don’t actually use traditional sprites, but more what amounts to custom tile layers for each one. This helped unlock characters from being mostly rectangular, and allow them to have poses with radically different shapes.
Fabian Sanglard has a great article about how character art was created for that system that’s well worth your time to have a look at. Well, maybe it’s worth it? I don’t know you. For all I know you’re looking for sewing advice. This is probably the wrong site for that. No offense to all you clothes-makers out there.
ROMs were expensive, and Street Fighter II required a lot of them, so it was important to make the most out of each one. A big rectangular shape around Edmond Honda would contain a lot of empty, wasted space. Imagine how much space they would have wasted with Dhalsim’s long stretchy legs! With this system, they only had to include the graphics data that would actually contain pixels.
This was in 1991, mind you. More recent development practices would probably have the data be compressed in storage, which would take care of all those empty pixels, or at least they could make a tool to handle figuring out which tiles should contain data. What the Street Fighter II artists had to do was create physical representations of each character on a physical board, chop that up into squares, and figure out what each tile had to contain, a laborious process.
Fabian reckons this system was used for other CPS-1 games, going back to at least Forgotten Worlds. Looking at the tile layouts of CPS-2 titles, it seems a lot more evident that they used a packing tool to handle fitting their characters into the memory space. For more info, please go check out the article!
Back in 2013, David Crane chimed in on a thread about Pitfall II. The Atari VCS (a.k.a. 2600) was not known for the quality of its music. For sound effects, especially noise effects like blasts and booms, it was fine, but its TIA chip didn’t have the frequency resolution to produce every musical note precisely, meaning some of it notes would sound a bit off.
Pitfall II’s music, some of the best on the system in the classic era
There was technically a way to produce almost arbitrary waveforms, though like many techniques on the system it was processor-intensive. It involved changing the volume on one of its sound channels in real time to simulate the waveform of the sound you wanted to make. That was fine so long as you didn’t need the processor to do anything else, and sadly, on the VCS, just displaying graphics relied heavily on the processor.
Pitfall II, VCS/2600 version. Image from Mobygames.
David Crane managed to get decent polyphonic music out of the VCS by using Pitfall II’s DPC chip, which Crane created himself, as a co-processor that figured out the right values to set the volume to produce the mixed waveform for the music at a specific time, which the machine’s overworked 6507 CPU could then read and send to the right volume register in the TIA every scanline. The process is explained (to the understanding of a sufficiently technical frame of mind) here. I think I understand it myself!
The fact that David Crane is still around, and so willing to discuss the many tricks he came up with to make his games, is a great blessing, as is the existence of the AtariAge forums themselves, which are a trove of classic gaming information.
Nowadays this technique has been refined and utilized in homebrew cartridge productions. A particular standout is the music from Champ Games’ version of Mappy, which is frankly amazing. Check it out:
I’ve been doing a lot of high-effort posts lately, even for things that should be fairly quick. Working to make this more sustainable, here’s a laid-back post that’s mostly just a Youtube video of a talk between the guys of Digital Foundry and Randy Linden, coder of the SNES port of DOOM, which uses the SuperFX chip to make the hardware push polygons at a rate that, while not stellar by PCs-of-the-time standards, at least not abysmal.
Let’s run down the differences of hardware:
PC running MS-DOS: targets VGA monitors, displays all its pixels in software, but makes up for it with a minimum requirement of a 386 running (if memory holds up over nearly 30 years) at 33 mHz.
SNES: Its processor is a much slower workalike of the 65C816, a 16-bit version of the 6502, running at 3.58 mHz. While it makes up for its slower clock speed with a simpler design, meaning instructions complete generally in fewer cycles, it’s hard to make up for that 10-fold difference in speed.
Their use of specialized graphics hardware was an important advantage, at the time, of consoles over personal computer hardware. Even many standard home microcomputers, like the Commodore 64 and Atari 800, had dedicated graphics hardware that helped games run better than what most PCs could do. Even when VGA came out, the standard had no hardware-level support for scrolling or sprites.
Consider what it takes to scroll a screen without hardware support: something in the system has to be able to move every pixel from one spot on-screen to another. The NES pulls this task off by having a bank of memory that its PPU can be pointed within, meaning the memory could stay in the same place, and the graphics chip would just work from a different region within it. Sadly, this technique is not amenable to 3D graphics, which usually do require every pixel on the screen to be recalculated every frame, either in software or hardware.
The SNES is known for having a rather slow chip for its time, but more demanding games tended to make up for it with co-processor chips included on the cartridges. The most well-known of these are the DSP-1, which functioned as a math co-processor; the SA-1, which was basically a second 65C816 running at around triple the speed and with a few added features; and the SuperFX, which ran at about the SA-1’s clock speed but functioned as a graphics accelerator. (The later SuperFX 2 ran at twice that speed.)
These were far from the only add-on chips included on Super Famicom and SNES carts. Since the SNES had a much larger address space than the NES’s 6502-clone, the need for mapper chips was much less, but these co-processors were used in a number of more notable games to help it make framerate goals.
Hm. Well, I tried making it a laid-back kind of post. Ah well, back to playing Live-A-Live.
When you start using emulators, it won’t be long before you’re brought up against the choice of which scalers to use, a bewildering collection of options with names like Nearest Neighbor, AdvMAME3x, and RotSprite.
Resizing pixel images in an intelligent way is a difficult problem for many reasons. Most techniques intended for use on photographs won’t apply, since they’ll produce unacceptably blurry results when applied to extremely low resolution art. Pixel art is designed so that every dot matters, and adding new pixels carelessly can cause problems, such as Mario flipping us the bird in the right-hand image below:
Mario vs MMarrioo:A possible result of bad upscaling.
Additionally, being done frequently in real-time emulation, scaling algorithms must be fast. Yet the fastest solution, called Nearest Neighbor, produces very blocky results, and also only really works well if images are scaled up to an integer multiple of the original in X and Y dimensions.
A good backgrounder of various issues is available from an old blog post here, but there’s been some interesting advancements in the field since then. RotSprite is a good contemporary solution that also can rotate pixel art images well.
A raycaster engine is a simple 3D engine that just draws lines from the player’s position to the nearest terrain wall for each horizontal pixel on the screen. It was what was used in one of the foundational 3D action games, id Software’s Wolfenstein 3D.
For those with a coding bent (the word bent seems so suitable when it comes to people who enjoy programming), Youtube account 3D sage demonstrates how to implement a raycaster in a series of three videos. The first one is embedded below:
Here are links to the whole series: Part 1 (17 minutes), Part 2 (14 minutes), and Part 3 (22 minutes)
Later he did another series on implementing the kind of engine that’s in DOOM, but we’ll look at that at a later date.
