Exploring Early ’90s Video Game Architecture With Another World

January 17, 2020 by Sharon Lin 21 Comments

Curious about past computer architectures? Software engineer [Fabien Sanglard] has been experimenting with porting Another World, an action-adventure platformer, to different machines and comparing the results in his “Polygons of Another World” project.

The results are pretty interesting. Due to the game’s polygon-based graphics, optimizations vary widely across different architectures, with tricks allowing the software to run on hardware released five years before the game’s publication. The consoles explored are primarily from the early ’90s, ranging from the Amiga 500, Atari ST, IBM PC, and Super Nintendo to the Sega Genesis.

The actual game contains very little code, with the original version at 6000 lines of assembly and the PC DOS executable only containing 20 KiB. The executable simply exists as a virtual machine host that reads and executes uint8_t opcodes, with most of the business logic implemented with bytecode. The graphics use 16 palette-based colors, despite the Amiga 500 supporting up to 32 colors. However, the aesthetics still fit the game nicely, with some very pleasant pixel art.

There’s a plethora of cool tricks that emerge in each of the ports, starting with the original Amiga 500 execution. Prior to the existence of the CPU/GPU architecture, microprocessors had blitters – logic blocks that rapidly modified data within the memory, capable of copying large swathes of data in parallel with the CPU, freeing up the CPU for other operations.

To display the visuals, a framebuffer containing a bitmap drives the display. There are three framebuffers used, two for double buffering and one for saving the background composition to avoid redrawing static polygons. Within the framebuffer, several tricks are used to improve the graphical experience. For scenes with translucent hues, special values are interpreted from the framebuffer index by “reading the framebuffer index, adding 0x8 and writing back”.

Challenges also come when manipulating pixels given each machine’s CPU and bus bandwidth limitations. For filling in bits, the blitter uses a feature called “Area Fill Mode” that scans left to right to find edges, rendering the bit arrays with spaces between lines filled in. Since the framebuffer is stored in five separate areas of memory – or bitplanes – this requires drawing the lines and filling in areas four times, multiplying by the hundreds of polygons rendered by the engine. The solution was to set up a temporary “scratchpad” buffer and rendering a polygon into the clean space. The polygon can then get copied to the screen area with a masked blit operation since the blitter can render anywhere in memory.

Intrigued? The series continues with deep dives into Atari ST, IBM PC, and upcoming writeups on SEGA Genesis/MegaDrive.

Adding A Co-Processor To Help SNES Games With Slowdown

August 18, 2019 by Erin Pinheiro 3 Comments

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.

Continue reading “Adding A Co-Processor To Help SNES Games With Slowdown” →

Doing What Id Couldn’t: Returning Music To Jaguar Doom

August 4, 2019 by Erin Pinheiro 16 Comments

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.

Software hacks are not the only things that the Jaguar fan base can do though, and a fine example of a hardware one is this custom mod showing what it could’ve looked like with the CD add-on in an integrated unit.

Continue reading “Doing What Id Couldn’t: Returning Music To Jaguar Doom” →

The Evolution Of Wireless Game Controllers

December 10, 2018 by Drew Littrell 14 Comments

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

Nintendo AVS 1985 Display — Nintendo AVS console deck and IR controller on display.

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.

Continue reading “The Evolution Of Wireless Game Controllers” →

Final Fantasy Exploit Teaches 32-bit Integer Math

September 19, 2018 by Bryan Cockfield 18 Comments

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.

Continue reading “Final Fantasy Exploit Teaches 32-bit Integer Math” →

Ted Dabney, Atari, And The Video Game Revolution

June 5, 2018 by Dan Maloney 29 Comments

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 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.

Continue reading “Ted Dabney, Atari, And The Video Game Revolution” →

Neural Networks Using Doom Level Creator Like It’s 1993

May 16, 2018 by Drew Risinger 12 Comments

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.

Example DOOM maps generated by AI. Each row is one map, and each image is one aspect of the map (floor, height, things, and walls, from left to right)

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!

Continue reading “Neural Networks Using Doom Level Creator Like It’s 1993” →