Metroid Prime

November 17, 2002

Collections

Metroid Metroid Prime

Franchises

Metroid

Platforms

Nintendo GameCube

Companies

Nintendo Retro Studios

Genres

Adventure Platform Puzzle Shooter

Add Trivia

Sort

Votes arrow_drop_up Submission Date

▲

▼

There is an unused scan image of what looks like a Shinesparking Samus. In an interview with Retro Studios, it was revealed that they were considering implementing the Speed Booster and Shinespark, but due to the difficulties implementing it, it was scrapped.

sell

person Outofmind23 calendar_month July 2, 2013

comment Comment (0) | link Source

▲

▼

Kraid was intended to return as a boss, but was scrapped due to time constraints. Kraid's character model was completely finished, but the there wasn't enough time left to create a fully polished boss fight.

"It was decided that Kraid was not imperative enough to the Metroid Prime project to run the risk of pushing up the release date in order to fit him in." -Gene Kohler

sell

person Pogue-Mahone calendar_month April 21, 2013

comment Comment (0) | link Source

▲

▼

During development, a flying insect-like enemy was removed from the game. It is speculated that it may have been an early design for the aerial pirates or possibly intended to serve as a boss at some point in the game.

sell

person cross307 calendar_month March 22, 2013

comment Comment (0) | link Source

▲

▼

During development, a four-armed gorilla enemy, possibly intended as a boss of the ice area, was removed from the game. Nintendo felt that some of the early models looked too much like monsters designed for an RPG and decided they did not fit in the Metroid world.

sell

person cross307 calendar_month March 22, 2013

comment Comment (0) | link Source

▲

▼

According to one of the game's tech leads Jack Mathews, shortly after Metroid Prime shipped, Nintendo told Retro Studios that a "bad batch" of GameCube CPUs shipped, and apparently this game was the only game that misbehaved on them. Upon seeing videos of the issue, it became clear to them what was going on:

"All animated objects were freaking out... we needed to actually slow down some of our code, because it was running too fast for these CPUs to handle! We needed to be able to test this, but Nintendo only had one dev kit with this CPU. We couldn't detect the CPU, and if we slowed it down too much, the game's framerate would tank. If we didn't slow it down enough, it would glitch. Even worse, we had to burn disks for this kit. So each test was hours. Even weirder was to see the problem, the kit had to be cold. Like, freezer cold. So we literally had to put the kit in the freezer, test the game for 15 minutes tops, then start all over. It was crazy. We literally were running the kit from the break room freezer to the TV, and loading save games as fast as possible to as many places as possible in 15 minutes, then trying new code, re-freezing, and back. I'll never forget it."

In retrospect, he wondered if it was possible to instead rig up the GameCube so it stayed in the freezer and let the wires run out to connect to the TV to save time running back and forth.

On the more technical side, Mathews explained:

"Our skinning used the locked cache DMA to read in data and the write gather pipeline to write it out. Most of the Nintendo samples used the locked cache for both read and write, so my method was a bit faster. But it also hit memory bandwidth limits. As I recall, the issue was that the write gather pipe on these broken CPU's wouldn't stall when it was full or properly report its status, so we had to keep inserting NOPs in the code to slow it down just enough to stop stalls from happening, but not so much to slow down the game."

When a player called Nintendo of America's support hotline about this animation problem, they would send them a new copy of the game disc with this updated code.

When this story was posted to Twitter in 2022, one user posted an older video of a graphics glitch positing that the issue is "caused by the ANCS file using the wrong CSKR for the suit model", and that it might be possible to simulate the issue outside of the hardware and software conditions it originally happened in. Mathews replied:

"I don't know if it was writing out less than we were putting in the write-gather, or throwing away and reusing from the buffer, but sort of along these lines, with more jittering and triangles all over the place. This example has coherent skinning, just a bad mapping... I think the WG pipe was a 96 byte circular buffer. So when it wouldn't stall, it would write bytes over earlier entries in the buffer before they could flush to main memory. These would still be four-byte aligned writes, so I think the way to emulate it would be to take blocks of anywhere from 4-32 bytes (a multiple of four) and move them back by 96 bytes in the skinning buffer."

Mathews also talked about how it would have been a bigger hassle to rewrite the skinning pipeline to use the locked cache, because it would have been a rewrite by taking the risk of adding new code and may have net slowed things down. Adding the NOPs wouldn't break anything and just moved the stalls from the memory controller to the PPC chip.

sell

person MehDeletingLater calendar_month September 16, 2023

comment Comment (0) | Source

arrow_right

Jack Mathews tweet:
https://twitter.com/jack_mathews/status/1590748677160566786

Older video of a graphics glitch:
https://www.youtube.com/watch?v=5f-N9WUHJwE

keyboard_double_arrow_leftFirst keyboard_arrow_leftPrev

Page 2 of 2

Nextkeyboard_arrow_right Lastkeyboard_double_arrow_right