This is really well outside the realm of simple repair, as the video demonstrates, the machine is basically totaled. There’s no monitor! The power supply is obviously kaput! They get it working though. HAPPY END!
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.
On Romhack Thursdays, we bring you interesting finds from the world of game modifications.
A hack of NES Metroid, Junkoid doesn’t offer many changes to the original game besides graphics and area maps. Most of the engine changes it has are pre-existing patches made by other people. It uses the Metroid map and save game patch, but only offers a map for the starting region. Fortunately, while it has some cool secret areas to find, its mazes aren’t particularly complex, and I was able to complete it without keeping any maps on paper.
Junkoid’s premise is that the game world is a dream had by its protagonist, which is its excuse to provide a variety of imagery without any great coherency to it. One area seems like it’s drenched in blood, which I am not usually a fan of) Another like it’s a cloning factory, dedicated to making clones of the heroine, but its boss is a penguin that acts mostly like Ridley.
For the most part it’s not too difficult going, but I found that the final boss could be very frustrating. It uses Mother Brain’s coding most as-is, and doesn’t have the Zebetite gates immediately before it so you can get by with fewer missiles, but it’s very easy to get tossed around by the various hazards of the final area, and the boss’s weak spot, which can only be harmed by missiles, was a bit too finicky when registering hits. Still though, I can vouch that it’s possible.
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:
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.
Live A Live is currently the toast of the Switch, with over 500,000 in sales since it was released. Not bad at all for a remake of a Super Famicom game from Square’s classic era that had never made it out of Japan until now.
AustinSV on Youtube presents a video that goes into some detail about what was changed between the versions. If you’ve played the original (I’ve played a fair bit of it through the popular fan translation from Aeon Genesis), you’ll know a few things were definitely tweaked. I remember the Prehistory, by far the funniest chapter, being rather more risque in its humor, although the fart jokes and poop flinging were left mostly intact. Some of the changes are really interesting; they translated the whole Middle Ages chapter in iambic pentameter!
\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!
While we’re on the topic of 16-bit Sonic, revealed last year by Lapper on Twitter, and recently boosted by Classic Sonic Deconstructed, it turns out that, because of a misplaced hitbox, you’re completely immune to the bomb attacks of the boss of Chemical Plant in Sonic the Hedgehog 2 if you’re crouching.
This is the boss’s only attack. If you’re standing on the middle platform and just duck when he’s attacking, you’re completely safe.
The past two Sundays have been devoted to Playstation cutscenes. Here’s one more.
Pepsiman is an infamous Japan-only PS1 title, created by KID, who produced the NES games Low G Man and Recca. The Pepsiman character was a mascot for Pepsi in Japan. How he managed to swing a Playstation game I don’t know. I assume it was released as a cheap promotional thing, similar to how Sneak King for Xbox 360 was distributed for $4.99 at Burger King in the U.S., but truthfully I don’t know where I got that impression. It’s probably false.
It had a low budget, so they put in these cutscenes with an American actor sitting at home with what I can only describe as way too much Pepsi, drinking, congratulating the player (in English), and exhorting them to consume the caramel-colored, cloyingly-sweet beverage.
The effect is akin to having bubbles of carbon dioxide diffusing through your brain. Please spend time in a decompression chamber after viewing, to avoid coming down with the Pepsi Bends.
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.
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.
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.
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!
Please forgive the two exclamation points in the title. We writers are only given a limited number of exclamation points to use every month by the shadowy Punctuation Cabal, but Punch-Out!!’s title has two of them in it, so to properly stylize it I have to use two each time. Wasteful! Oops, there’s another one. I’m just going to save them from here on out. But anyway.
YouTuber Pap is a TAS speedrunner, meaning, he deals with absolutes. He knows the state of the machine, and isn’t limited by any puny human reaction times, but works by recording button sequences that can be played back infallibly. He asked a question: what’s the minimum number of punches needed to play through the main game of Punch-Out? The answer is 120, but since the game has significant randomness, it’s really unlikely.
He presents what is probably the definitive answer, but that’s not really the interesting thing about it. His video is a master class on the game’s state, how it determines knockdowns and knock-outs, and how it awards stars. Some interesting things revealed:
If a fighter ever gets up on a count of 1, connecting with a single star punch can knock them back down immediately.
Many star punches are awarded based on successful punches where the opponent is not stunned or knocked down. You get them on a cycle based on a count that differs with each fighter. Special timing doesn’t have anything to do with it; it’s if the hit was successful of not. Late punches after stunning give star punches because the opponent is no longer stunned, not because they’re late.
On top of that, there are random stars that are awarded sometimes. This randomness is significant for the minimum punch count challenge. But these stars can only occur if you already have at least one star! Keeping a star in reserve actually helps you earn more stars more easily.
You having full health affects multiple boxers in significant ways, including sometimes turning knockdowns into knockouts.
Soda Popinski has a trick where, if you hold down while he’s preparing to uppercut, he delays. He can then be gut-punched, and if you do, your next star punch will always knock him down.
In the second fight with Bald Bull, I always wondered why it was difficult for me to counter his bull charge at first. Turns out, it wasn’t just me. The “long” version of his charge has a shorter success window, of just four frames! The “short” version, which happens if you dodge the long version, however, has a window of 13 frames. It’s so long it’s almost a gimmie. (I am resisting the urge to expend another exclamation point there.)
The greatest minimum number of punches needed to beat any opponent is a tie between King Hippo (an atypical opponent in many ways) and Mr. Sandman (not surprising at all) at 20.
The lowest minimum number is one, which can be gotten from Glass Joe (of course), the rematch against Piston Honda (huh) and the rematch against Bald Bull (what?).
Mike Tyson/Mr. Dream can be defeated in six punches.
This is a channel on YouTube of various Super Metroid glitches and weirdness. A lot of it is pretty deep magic, and they tend to throw around evocative terms like Murder Beam, Chainsaw Beam, and even Spacetime Beam. Those links are useful in understanding what in the burning acidic heck the narrator is talking about. Knowing and caring about the gameplay of Super Metroid is, of course, required for comprehension.
But if you do know about Super Metroid, and you do care about learning about some of the more ridiculous glitches in videogamedom, then you’re in for something that is a reasonable approximation of entertainment.
The name of the channel refers to a debug feature left in Super Metroid’s code, that can be pulled off without hyper-obscure tech, although in the process it’s likely to crash your game. When you enter into the room of the of the bosses, the Golden Torizo, if all of the face buttons are held down during the transition, your equipment will be overwritten by a number of items. The code gives you all of the beam weapons in the game, which is good, but also turns them all on at once, producing the afore-mentioned Murder Beam, which will likely crash the game, not good. The opposite of good.