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.
\An awesome fansite about this history of classic hardcore NeoGeo run-n-gun series Metal Slug, there’s lots of information and screenshots scavenged from Japanese gaming magazines about its development!
Early screenshot of a development version of Metal Slug, scavenged from Gamest. All images in this post from Metal Slug M.I.A., which has many more of them!
Early in development, you spent the entire game in the Metal Slug tank. You could rescue soldiers who would then help you in battle, such as the one in the white uniform in this image riding on the Slug.
Beta screenshot of the final boss fight with General Morden.
This is one going out to all you developers out there, either current or aspiring.
It’s amazing to me how fussed, nay, obsessed-over the 16-bit Sonic the Hedgehog games are even to this day. There are a lot of good things about them, and arguably the best is their platforming engines, which are among the best in the field. They take advantage of the processing power of the Genesis/Mega Drive, fueled by a Motorola 68000 processor, the same processor as the classic Apple Macintosh, clocked only slightly slower. This was basis of Sega’s infamous “blast processing” slogan at the time, touting how much faster the Genesis was than the Super Nintendo Entertainment System. This was somewhat unfair, as SNES carts often came with supplemental chips in them that acted like co-processors, and was of a completely different architecture as well with different characteristics, but it did make the Sonic engine possible. A lot of the credit also goes to Sonic programmer Yuji Naka, who is legendary in game coding circles for a very good reason.
If this is the kind of discussion that makes your heart race, we’re glad to have you reading Set Side B! If it’s not, that’s okay. I’m a bit stymied myself, even though I love dives like this. (All images in this post from Sonic Retro.)
The result of the Genesis’s power and Naka’s expertise was a game engine with, yes, raw speed, but also a lot of nuance. If you jump and land on an enemy or monitor, you can control the height of your rebound, no matter how fast you were going when you hit it. If you jump while on a slope, you don’t jump straight up but away from it, which takes some getting used to at first but can be taken advantage of. There’s lots of fun little cases like these, and figuring them out, and their implications, is the source of a lot of the joy of playing Sonic the Hedgehog for the first time.
Those two places where the slope only intrudes slightly into Sonic’s ground tile are what get me.
I’d even argue, without the solid engine, and great level design taking advantage of it, all of Sega of America’s marketing efforts, which formed the foundation of the media juggernaut that Sonic has become today, with several cartoon series and comic books, and two successful movies and a third one in the works, would have been for naught.
Judging by the later 2D adventures, the nuances of Sonic the Hedgehog’s engine are difficult to grasp without a good amount of effort. It is likely that Sega themselves don’t have the institutional memory to understand how they worked, which is why they went to Christian “The Taxman” Whitehead, and others from the fan game community, to make Sonic Mania, which has a faithful recreation of the original games’ physics.
Why has no one made a Sonic half-pipe trick skateboarding game?
Bringing it back around, the obsession of the Sonic fan community has produced a number of disassembles of the game’s code, which have served as the basis for a wide array of romhacks of rather shocking levels of quality. I wrote about many of those in the Someone Set Up Us The Rom ebooks (ahem).
They also served as the basis for the subject of this post, the physics descriptions at Sonic Retro. Here is basically all you need to make a Sonic-style platformer. Synthesizing this and putting it into practice is a formidable task on its own, but it’s a doable one, and you don’t have to read source code (other than your own) to do it. To those who attempt this task, we salute you! And let us know how it goes!
It’s hard to believe that Legend of Zelda fangame construction system Zelda Classic and ZQuest is 23 years old. Many such systems have fallen by the wayside during that time, but Zelda Classic continues on. Its first versions were made for DOS, but it continues to see improvements to this day.
ZQuest has this weird interface where they rolled their own controls for everything. The dev system seems to be rendered in Allegro.
Zelda Classic and ZQuest are made specifically to make overhead view action-adventures in the Legend of Zelda style, to the extent that it has graphic sets taken directly from the games and many items that work like their console counterparts.
It even simulates many of the quirks from the various Zelda series titles. And yet, it doesn’t require you to abide by them. Pretty much every technical or creative limitation of the 2D Zelda series has an option to disable it if you like, but if for some reason you consider it intrinsic to the experience you can keep it too.
The graphics can be completely changed out. With it, you can make a game that doesn’t look anything like a Zelda title, which I suspect is why it’s been able to survive 23 years in a legal landscape overseen by a Nintendo increasingly draconian in its approach to guarding its intellectual property. Still, it’s pretty heavily aimed at making Zelda fangames, right down to having pages and pages of checkboxes for every known quirk of Zelda engine behavior.
Look at that gloriously pedantic list of quirks! The ZQuest developers are awesome.
While it does offer a scripting facility (which it’s difficult to find documentation for), ZQuest is mostly a construction set type of program. You place tiles and enemies, lay out overworlds and dungeons, decide what items to include, and go. The program itself has little in the way of documentation but the site has a tutorial that should help one get started. I strongly suggest, if you are interested in creating for this system, that you read it.
A lot of the gaming web has been fawning over Kirby and Smash Bros. creator Masahiro Sakurai’s design videos. I haven’t had the chance to look at them yet, but they look interesting at least. They’ve been coming out at a good clip, like one every two days.
Sakurai’s star is so high right now, that it’s worth noting that (going by memory) he left Nintendo with a bit of a cloud over his head, after Kirby Air Ride was seen as something of a failure. Nowadays KAR (nice acronym!) is seen as an underrated classic, and I have put many hours into its City Trial mode, which is terrific, a tiny open-world high-speed racing/party game. More people should have the chance to play it; it is unique, which is something I can’t say about many other games. While the 3DS version of Smash Bros. has a mode inspired by it, in versus mode human players cannot interact with each other during the exploratory portion of the game, which harms it somewhat.
At the height of his abilities, Sakurai can make really interesting and new kinds of games, like Smash Bros. was, and like Kirby Air Ride and (the sadly neglected these days) Meteos are. It’s a shame that Smash is so popular, one of Nintendo’s biggest tentpoles, enough to crowd out his other work. I’m really interested to see what the next crazy idea he comes up with will be!
Another interesting game-related video he’s made is about the beloved old pinball game that was included with Windows during the XP days, but vanished with Vista. The game’s exclusion was the subject of a blog post by former Microsoft developer Raymond Chen, who mentioned that he had trouble getting the game to work correctly under 64-bit Windows. The ball kept clipping through objects, and sometimes falling through the plunger and out of the table. NCommander’s examination indicates that the problem was probably related to floating point precision as Chen had said, but that the cause was probably more complicated than that, and may have had to do with issues getting the game to run correctly on Intel’s ill-fated Itanium architecture, their first attempt at a 64-bit processor.
NCommander’s explorations were made possible by the discovery that, although there was no way to get the installer to offer it, the 3D Pinball game files are on the CD for the various editions of XP for Itanium. For more information, I refer you to the video, embedded above.
Notably, Chen has responded to NCommander’s video with more details about the game’s removal, which make the story even more interesting, bringing in Alpha AXP, a second obscure 64-bit architecture that could run Windows XP.
It should be said that all of this is much more technical than the usual post here. Please don’t freak out too badly if this makes little or no sense to you. We’ll have something marginally more comprehensible for you tomorrow.
The book also contains interesting information on the licensing and approval process! Some things specifically listed as potential issues for approval (page 1-2-4 to 1-2-5) are the player being able to get somewhere without hope of escape, the inability to pause somewhere during gameplay, “inconsistent scoring methods,” calling the controller or cartridge by unacceptable terms like “joystick” or “cassette,” accidentally leaving Super Famicom-style colored buttons in depictions of the controller, and whether there are vowels in the password system.
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.
