The Super Nintendo port of Gradius III is notable for being close to the arcade original, with its large, bright and colorful graphics. However, due to the limitation of the console’s hardware, the port is also well known for having constant slowdowns during gameplay, particularly during later sections. [Vitor] hacked away at the game and made a patched version of the ROM use a co-processor to eliminate those issues.
The slowdown seen here in Gradius is not uncommon to SNES players, many games of that era suffer from it when several sprites appear on the screen at once. This is partially due to the aging CPU Nintendo chose, supposedly in order to maintain NES backwards compatibility before the idea got scrapped. Unable to complete its tasks by the time the next frame needs to be shown, the hardware skips frames to let the processor catch up before it can continue. This is perceived as the aforementioned slowdown.
Around the later stage of the SNES’s life, games started using additional chips inside the cartridges in order to enhance the console’s performance. One of them is the SA1, which is a co-processor with the same core as the main CPU, only with a higher clock rate. By using it, games had more time to run through the logic and graphics manipulation before the next frame. What [Vitor] did was port those parts of Gradius III to the SA1, essentially making it just like any other enhanced cartridge from back in the day.
Unlike previous efforts we’ve seen to overclock the SNES by giving it a longer blanking time, this method works perfectly on real unmodified hardware. You can see the results of his efforts after the break, particularly around stage 2 where several bubbles fill the screen on the second video.
While the rest of the world has by and large forgotten the Atari Jaguar, the generously marketed console still has a fan base, and even some dedicated hackers prodding away at it. [Cyrano Jones] is one of them, and he managed something many considered unthinkable: restoring in-game music to the Jaguar port of Doom.
The Jaguar version of the classic shooter was developed by id Software themselves, and is generally considered one of the better console ports. For example, the large number of buttons on the Jaguar controller allowed players to select weapons directly rather than having to cycle through them. Unfortunately, the complete lack of music during gameplay was a glaring omission that took several points off of an otherwise fairly solid presentation.
The common culprit blamed for this was that the Jaguar’s DSP was already being used for math processing, so it didn’t have any cycles left for music playback. Coupled with a tight deadline, id probably cut their losses and released it without in-game music rather than try and spend more time engineering a solution. To compensate for the lack of in-game music, id did include the famous soundtrack in the intermission screens rather than entirely strip it out.
As [Cyrano] found out by studying the source code that’s been available since 2003, sound effects in the Jaguar version of Doom are played using something called a “ring buffer”: a cyclical fixed-length data buffer which constantly gets outputted as audio. With a patch of unused memory he could fit a second ring buffer in, rendering the music to it with close to no performance hit elsewhere in the code and then mixing both buffers for the final audio output. It looks as though id already had some of this solution in place, but with enough issues that forced them to abandon the idea in order to release the game on time.
The story goes that Atari was developing a premium model of their popular home video game console, the Atari 2600, for the 1981 fiscal year. Internally known as the Stella RC, this model revision promised touch sensitive game selection toggles, LED indicators, and onboard storage for the controllers. The focus of the project, however, was the “RC” in Stella RC which stood for remote control. Atari engineers wanted to free players from the constraints of the wires that fettered them to their televisions.
Problem with the prototypes was that the RF transmitters in the controllers were powerful enough to send a signal over a 1000 ft. radius, and they interfered with a number of the remote garage door openers on the market. Not to mention that if there were another Stella RC console on the same channel in an apartment building, or simply across the street, you could be playing somebody else’s Pitfall run. The mounting tower of challenges to making a product that the FCC would stamp their approval on were too great. So Atari decided to abandon the pioneering Stella RC project. Physical proof of the first wireless game controllers would have been eliminated at that point if it were created by any other company… but prototypes mysteriously left the office in some peculiar ways.
“Atari had abandoned the project at the time…[an Atari engineer] thought it would be a great idea to give his girlfriend’s son a videogame system to play with…I can’t [comment] about the relationship itself or what happened after 1981, but that’s how this system left Atari…and why it still exists today.”
– Joe Cody, Atari2600.com
Atari did eventually get around to releasing some wireless RF 2600 joysticks that the FCC would approve. A couple years after abandoning the Stella RC project they released the Atari 2600 Remote Control Joysticks at a $69.95 MSRP (roughly $180 adjusted for inflation). The gigantic price tag mixed with the video game market “dropping off the cliff” in 1983 saw few ever getting to know the bliss of wire-free video game action. It was obvious that RF game controllers were simply ahead of their time, but there had to be cheaper alternatives on the horizon.
Out of Sight, Out of Control with IR Schemes
Video games were a dirty word in America in 1985. While games themselves were still happening on the microcomputer platforms, the home console business was virtually non-existent. Over in Japan, Nintendo was raking in money hand over fist selling video games on their Famicom console. They sought to replicate that success in North America by introducing a revised model of the Famicom, but it had to impress the tech journos that would be attending its reveal at the Consumer Electronics Show (CES).
The prototype system was called the Nintendo Advanced Video System (AVS). It would feature a keyboard, a cassette tape drive, and most importantly two wireless controllers. The controllers used infrared (IR) communication and the receiver was built-into the console deck itself. Each controller featured a square metallic directional pad and four action buttons that gave the impression of brushed aluminum. The advancement in video game controller technology was too good to be true though, because the entire system received a makeover before releasing as the Nintendo Entertainment System (NES) that Christmas. The NES lacked the keyboard, the tape drive, and the IR controllers and its change in materials hardly captured the high-end flash of the AVS. The removal of IR meant the device was cheaper to manufacture. A decision that ultimately helped the NES to become a breakout success that in turn brought back dedicated video game consoles single-handedly.
One of the fun things about old video games, besides their obvious nostalgia, is that some of the more popular games have been pried apart and tinkered with for years, leading to a lot of new “development” within the games. This often uncovers some hidden gems that gamers might not have had any knowledge of during the game’s heyday, like this coding oddity found in Final Fantasy 7 that illustrates a lot about how 32-bit processors do math.
The original PlayStation used a 32-bit RISC processor, but the most significant bit could be used for integer signing. This means that if you have an integer that has a value of 2,147,483,647 (01111111111111111111111111111111 in binary) and you add one, the value is suddenly negative 2147483648 because the most significant digit is also an indicator of the integer’s sign. In this situation, the integer is said to “overflow”. In Final Fantasy 7, if you can somehow get a character to deal 262,144 damage in one hit (much less than two billion, due to the way the game does damage calculations), the game has a little bit of a meltdown.
[4-8Productions] had to do a lot of work to show how this glitch can be exploited in the game as well. Usually damage in this game is limited to 9,999 but under certain configurations (admittedly obtained by using other exploits and tools available for FF7 like a savegame editor) two of the characters can deal more damage than this critical value, exposing the 32-bit processor’s weak spot.
Even though integer signing is a pretty basic concept for most of us, the video is definitely worth a watch especially if you’re fans of the classic game. Of course, Final Fantasy 7 isn’t the only classic that has been exploited and reverse-engineered to the extreme. You can use a Super Mario World level to implement a calculator now, too.
It may be hard for those raised on cinematic video games to conceive of the wonder of watching a plain white dot tracing across a black screen, reflecting off walls and a bounced by a little paddle that responded instantly to the twist of a wrist. But there was a time when Pong was all we had, and it was fascinating. People lined up for hours for the privilege of exchanging a quarter for a few minutes of monochrome distraction. In an arcade stuffed with noisy pinball machines with garish artwork and flashing lights, Pong seemed like a calm oasis, and you could almost feel your brain doing the geometry to figure out where to place the paddle so as not to miss the shot.
As primitive as it now seems, Pong was at the forefront of the video game revolution, and that little game spawned an industry that raked in $108 billion last year alone. It also spawned one of the early success stories of the industry, Atari, a company founded in 1972. Just last week, Ted Dabney, one of the co-founders of Atari, died at the age of 81. It’s sad that we’re getting to the point where we’re losing some of the pioneers of the industry, but it’s the way of things. All we can do is reflect on Dabney’s life and legacy, and examine the improbable path that led him to be one of the fathers of the video game industry.
Readers of a certain vintage will remember the glee of building your own levels for DOOM. There was something magical about carefully crafting a level and then dialing up your friends for a death match session on the new map. Now computers scientists are getting in on that fun in a new way. Researchers from Politecnico di Milano are using artificial intelligence to create new levels for the classic DOOM shooter (PDF whitepaper).
While procedural level generation has been around for decades, recent advances in machine learning to generate game content (usually levels) are different because they don’t use a human-defined algorithm. Instead, they generate new content by using existing, human-generated levels as a model. In effect they learn from what great game designers have already done and apply those lesson to new level generation. The screenshot shown above is an example of an AI generated level and the gameplay can be seen in the video below.
The idea of an AI generating levels is simple in concept but difficult in execution. The researchers used Generative Adversarial Networks (GANs) to analyze existing DOOM maps and then generate new maps similar to the originals. GANs are a type of neural network which learns from training data and then generates similar data. They considered two types of GANs when generating new levels: one that just used the appearance of the training maps, and another that used both the appearance and metrics such as the number of rooms, perimeter length, etc. If you’d like a better understanding of GANs, [Steven Dufresne] covered it in his guide to the evolving world of neural networks.
While both networks used in this project produce good levels, the one that included other metrics resulted in higher quality levels. However, while the AI-generated levels appeared similar at a high level to human-generated levels, many of the little details that humans tend to include were omitted. This is partially due to a lack of good metrics to describe levels and AI-generated data.
We can only guess that these researcher’s next step is to use similar techniques to create an entire game (levels, characters, and music) via AI. After all, how hard can it be?? Joking aside, we would love to see you take this concept and run with it. We’re dying to play through some gnarly levels whipped up by the AI from Hackaday readers!
Paradise means something different for everyone, it could be a sitting by a fire on a rainy night or lying on a sun-kissed beach. But for us, and makers like [liltreat4you], it’s a well stocked scrap pile out behind the house. After buying a racing wheel and pedals for his Xbox, he took a trip out to his little slice of paradise and found nearly all the hardware he needed to build a professional looking race simulator. According to his breakdown, most of the money he spent on this build ended up going into that sweet red paint job and the speed-enhancing stickers.
Not all of us are as lucky as [liltreat4you], and we probably won’t just happen upon a driver’s seat out of a Mazda, or a bunch of perfectly bent metal pipes from an old trampoline out on the back forty. But trolling Craigslist or cruising around for flea markets can still get you parts like these for cheap, so try not to be too discouraged if your backyard isn’t quite as well stocked.
Once he had the metal pipes and seat from the car, the rest of the build came together pretty quickly. After building an oval out of his salvaged pipes, he attached the seat and the arms that would eventually hold the steering wheel and display. A plate was also added at the bottom for the pedals to sit on. By using long bolts, [liltreat4you] was even able to add a degree of adjustment to the wheel position. Being that he got his seat out of a real car, there’s the usual adjustment you’d expect there as well.
Speaking of which, [liltreat4you] casually mentions that you should disconnect the battery of the donor vehicle before taking out the seat, as it’s possible that the removal of the seat or the disconnection of the seat harness can cause the airbags to deploy. We can neither confirm nor deny this, but it’s probably safe advice to follow.