Displaced Gamers’ series on investigating design and programming problems with NES games continues with a game that I’m surprised isn’t more notorious, Ikari Warriors. (21 minutes)
The biggest problem with Ikari Warriors is probably that it was ported by infamous anonymous NES developer Micronics, who even in their best efforts tended to produce buggy, janky messes. Some other games they made: Ghosts & Goblins, 1942, Tiger-Heli, Elevator Action, Super Pitfall and Athena. All the other problems have their root in that.
Ikari Warriors runs at 15 fps. One game frame for every four screen frames! It uses expensive multiply routines instead of look-up tables for movement! Everything is slow even accounting for that! And it tries to adapt the arcade game’s character rotation system, which supports 16 directions (even though there are only character graphics for 8 of them), and forces the player characters to rotate through them to move.
All of this overhead makes Ikari Warriors really slow and frustrating to play. Displaced Gamers not only diagnoses the problem, but even makes a game attempt to fix them. And they come to the conclusion that it has additional problems, beyond even these, and really needs a bit of a redesign to really make it playable. Ah well, it was a good attempt.
Displaced Gamers’ Behind the Code series is one of the best explainers of the quirks of NES games on Youtube. It’s not afraid to dive into the assembly code itself if need be, but its videos can often be understood by people without deep technical backgrounds.
Watch the video for the full spiel, but here’s a summary.
Once upon a time, in the waning days of the Famicom, Konami planned to release a game called Arc Hound in Japan. It was going to be another of their trademark run-and-gun shooters, along the lines of Contra. It even received coverage in enthusiast magazines in Japan, and it probably would have used one of Konami’s bespoke mapper chips like the VRC6 that the Japanese version of Castlevania III used.
Arc Hound was likely far into development when the decision was made to not release it in the Japanese market. Producing a game cartridge requires a substantial investment in parts and marketing, of course, and they must have judged that they couldn’t make enough of a profit off of it in their home territory: the Super Famicom was already out, as well as Contra III on that platform. But the NES still had a little bit of life left in it in the US, so they decided to give the game a shot over here, as a title in the Contra series
A big problem there was Nintendo’s policies towards manufacturing NES games. Nintendo demanded the right to build all the licensed software for the NES, and further restricted most (although not all) publishers to using Nintendo’s own family of mappers. Konami had been forced to revise their games to use Nintendo’s mappers in other games: Castlevania III famously used a different mapper in Japan, one that offered greatly expanded sound capabilities that worked through the Famicom’s sound channel pass-through, but was incompatible with the NES.
Extra sound channels are nice, but the primary use for most mapper chips is bank switching, swapping different sections of a cartridge’s data into the Famicom/NES’s 6502-workalike’s 64K address space, and also potentially making different sections of the game’s graphics data visible to the PPU graphics chip.
Behind the Code’s examination of the game program reveals that a large portion of the time of each frame is spent in setting up bank switches. Whether it was coded poorly, or just that Konami didn’t want to pay to include a mapper with more a more efficient bank switching mechanism, the game wastes a lot of time just pulling in different banks of data to be visible to the NES’s hardware. So it is that Contra Force could have run a lot better, but Konami either didn’t want to expend the coding effort, or pay for the the mapping hardware, to allow it to do so.
Presumably, somewhere in Konami’s archives, there is a version of Arc Hound that uses a VRC chip to handle mapping, and that runs much more smoothly. Maybe someday it’ll come to light, although I wouldn’t lay any bets on it. More likely perhaps is that someone will hack up the code and make such a version themselves. Who knows?
A bit of scanline flickering is a fairly common problem on the NES. Even Super Mario Bros. 3 had it, and that game was made by Nintendo themselves.
Game graphics in the 8- and 16-bit ages often came down to tricky hardware manipulation. The art of doing raster effects, changing the registers in the video hardware so as to divide the screen into different sections, ultimately comes down to timing. On the Atari VCS/2600, nearly all the graphics had to be done that way, but it was still a useful technique for over a decade after that.
A lot depends on the specifics of the video chip, a custom-built piece of silicon developed for the express purpose of taking graphics defined in memory and folding it, like electronic origami, into a shape that the TV would perceive as a broadcast signal. At that time, while it might still have been possible with clever coding, CPUs weren’t nearly fast enough to do that job themselves and still produce acceptable graphic quality and run game logic. (If you want to see what it would be like, I refer readers interested in doing it the very hard way to the amazing Freespin demo, which runs on a 1541 disk drive, and no video hardware at all.)
Older NES games used a supported bit of hackery called the “Sprite 0 Hit,” a signal the PPU would send at the moment the first of the system’s 64 sprites began to be drawn. By watching for it, games could do rudimentary raster effects on a system not designed for them. The issue there was processor time: the Sprite 0 Hit feature wasn’t hooked up to an interrupt line, so the program had to continually watch for it, checking a memory location repetitively over and over until it changed. Some games spent large portions of their runtime in a tight loop checking for the Sprite 0 Hit. Since, from the program’s perspective, the signal might come at any time, the loop needed to be tight, meaning the game couldn’t spend that time doing other work or else it might be delayed in responding to the extremely time-sensitive signal.
The MMC3 mapper had a special function though that could time out when a programmable scanline was reached, and send the processor an interrupt request at that time, greatly freeing up the processor for doing other things with that time. But not all programmers understood the best way to use it, which is why Mega Man 3 has some scanline glitching in a couple of very visible places, in the pause window and on the level select screen.
Displaced Gamers’ Behind the Code series, which we’ve linked to multiple times in the past, has done an exposé looking into how Mega Man III’s glitches happen (28 minutes), and even wrote some code that erases all trace of them. As usual for Behind the Code, the explanation is fairly technical, especially of the fix, but the first half of it is fairly comprehensible. No one says you have to watch the whole thing. Or, indeed, any of it, but I always enjoy them!
Displaced Gamers’ excellent Being The Code series on Youtube looks into what causes Nintendo’s NES Tetris to crash at really really high levels, over level 150. In the process, it goes through how that game displays and adds scores together. Have a look (22 minutes)!
We presented Displaced Gamers’/Behind the Code’s video on the jankiness of kusoge disgrace Dr. Jekyll and Mr. Hyde back on Saturday. They did another video on that game, that delves into why the game’s frame rate is so inconsistent. In summary, its engine throttles its framerate in a terrible way, using long delay loops. It’s a pretty awful idea! It’s 19 1/2 minutes long. The video claims it’s even geekier than their first video on the game, but I think it’s actually slightly less technical, at least it doesn’t fill the screen with as much 6502 assembly code.
Another fact about J&H: the Japanese version had two full levels that were cut from the U.S. version, which replaced them with replays of other levels. It made a bad game even worse!
Now, because of Behind The Code, you know more about the Dr. Jekyll and Mr. Hyde game than many much better NES titles. Congratulations!
It’s 19 minutes long, and is even geekier than is usual for us, going into a disassembly of the game’s machine code in its quest to make the game marginally less awful.
While we’re on the subject, did you know that Jekyll & Hyde has a secret ending? Both endings are shown here (4 minutes):
The “bad” ending is the normal one, and shorter, but is arguably a happier conclusion to the story. To get it, all you have to do is get to the end of Stage 6 with Jekyll. That’s all.
To get the other ending, get to Stage 6 with Jekyll, then turn into Hyde and get to the end of his version of the stage. Usually, if Hyde gets as far into his level as Jekyll has gotten into his, he’s struck by lightning and dies. But in this level he’ll be allowed to reach the end of his version of the level for some reason, where there’s a boss! Beat it, and when you return to Jekyll’s world the enemies will be gone, and he’ll be free to finish the level without harassment. However, ending events will be different….
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!
Displaced Gamers‘ Behind the Code series doesn’t get new videos often, but they’re always great. This one is more technical than usual, but I don’t think it’s really all that technical. It’s about how the NES processes and renders its sprites, particularly explains why there’s a eight sprite per scanline limit, and even reveals a couple of games that use that limit to produce special effects!
The gist: while each scanline is being prepared for display, the NES’ PPU looks through the entries for the machine’s 64 hardware sprites in order, finds the first eight that will display on the current line, and copies their attribute data to a small area of internal RAM. There is only space there for eight sprites, so, the NES cannot display more than eight sprites in a single scan line. Any later sprites in the primary attribute data won’t have room to be copied, and so the PPU won’t be able to display them.
One thing it notably doesn’t cover, however, is how games implement priority shuffling to cause sprites to flicker instead of not display at all. The video suggests that that might be coming in a future video….
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.
