Nintendo 64 programming characteristics

The Nintendo 64's programming characteristics describe the elements of writing software for the Nintendo 64 (N64) gaming system.

History

N64 was released in 1996. At the time, The Economist described the system as "horrendously complex".[1] The difficulties were said to be a combination of oversight on the part of the hardware designers, limitations on 3D graphics, technology limits of that time, and manufacturing issues.

As the Nintendo 64 reached the end of its lifecycle, hardware development chief Genyo Takeda referred to its programming challenges using the word hansei (Japanese: 反省 "reflective regret"). Takeda said, "When we made Nintendo 64, we thought it was logical that if you want to make advanced games, it becomes technically more difficult. We were wrong. We now understand it's the cruising speed that matters, not the momentary flash of peak power."[2]

Characteristics

Texture cache

The texture cache was 4 KB in size. Its small size led developers to stretch small textures over a comparatively larger space. The console's bilinear filtering only blurs them. When mipmapping is used, texture width requirements and the extra storage for the mipmap levels limit the largest mipmap level to 2 KB. Toward the end of the Nintendo 64's market cycle, some developers precomputed their textures using multi-layered texturing and small texture pieces that were heavily clamped, to simulate larger textures. Examples of this workaround are found in Rare's Perfect Dark, Banjo-Tooie, Conker's Bad Fur Day, and in Factor 5's Indiana Jones and the Infernal Machine.[3] Some games with non-realistic aesthetics use plain colored Gouraud shading instead of texturing on certain surfaces (e.g., Super Mario 64).[4]

The big strength was the N64 cartridge. We use the cartridge almost like normal RAM and are streaming all level data, textures, animations, music, sound and even program code while the game is running. With the final size of the levels and the amount of textures, the RAM of the N64 never would have been even remotely enough to fit any individual level. So the cartridge technology really saved the day.

— Factor 5, Bringing Indy to N64, IGN[3]

Fill rate

Many Nintendo 64 games are fill-rate limited, not geometry limited. Multiple techniques were designed to maximize the fill rate. The RDP's (Reality Drawing Processor) fill rate is significantly affected by microcode optimizations — often specifically with Z-buffering. Thus, for maximum performance,[5] the microcode supplied by Nintendo was replaced by each developer.[3] The Nintendo 64's polygon per second rating is about 160,000 with hardware features enabled.[6] Some of the more polygon-intense Nintendo 64 games include World Driver Championship, Turok 2: Seeds of Evil, and Indiana Jones and the Infernal Machine.[3]

Microcode

The graphics and audio co-processor is programmable through microcode.[7] By altering the microcode, a developer can access different operations, create new effects, and optimize for speed or quality. While promoting this feature of custom microcodes, Nintendo initially refused to share information on how to use the related microcode tools. This was due to the fear that it would be copied by their competitors. However during the console's last few years, Nintendo shared the microcode information with a few developers. Nintendo's official code tools are basic, with no debugger and poor documentation.

SGI's default microcode for Nintendo 64 is called "Fast3D", which some developers claimed was poorly profiled for use in games. Although it generates more than 100,000 high accuracy polygons per second, this microcode is optimized more for accuracy than for speed, and performance suffered. Nintendo's "Turbo3D" microcode allows 500,000–600,000 normal accuracy polygons per second. However, due to the graphical degradation, Nintendo officially discouraged its use. Cmpanies such as Factor 5,[3] Boss Game Studios and Rare, were able to write custom microcode that reportedly runs their game engines better than SGI's standard microcode.

One of the best examples of custom microcode is Factor 5's N64 port of the Indiana Jones and the Infernal Machine PC game. The Factor 5 team aimed for the high resolution mode of 640×480[8] because of its visual crispness. The machine was said to be operating at its limits while running at 640×480. The Z-buffer could not be used because it alone consumed the already constrained texture fill rate. To work around the 4 KB texture cache, programmers came up with custom texture formats and tools. Each texture was analyzed and fitted to best texture format for performance and quality. They took advantage of the cartridge as a texture streaming source to squeeze as much detail as possible into each environment and work around RAM limitations. They wrote microcode for real-time lighting, because the supplied microcode from SGI was not optimized for this task, and because they wanted to have more lighting than the PC version. Factor 5's microcode allows almost unlimited realtime lighting and significantly boosts the polygon count. In the end, the N64 version is said to be more feature-rich than the PC version, and is considered to be one of the unit's most advanced games.[3]

Factor 5 again used custom microcode with games such as Star Wars: Rogue Squadron and Star Wars: Episode I: Battle for Naboo. In Star Wars: Rogue Squadron, the team tweaked the microcode for a landscape engine to create the alien worlds. For Star Wars: Battle for Naboo, they used what they learned from Rogue Squadron and made the game run at 640×480, also implementing enhancements for particles and the landscape engine. Battle for Naboo has a long draw distance and large amounts of snow and rain, even in high resolution mode.[9]

Memory

Featuring a non-unified memory architecture, the console's RDRAM has very high access latency,[10] which is contrasted with its high bandwidth advantage. The R4300 CPU's ability to access RAM is constrained by its requirement to route all RAM accesses through the RCP, and by the fact that it can not use DMA.

See also

References

  1. ↑ "Nintendo Wakes Up." The Economist Aug 03 1996: 55-. ABI/INFORM Global; ProQuest Research Library. Web. 24 May 2012.
  2. ↑ Croal, N'Gai; Kawaguchi, Masato; Saltzman, Marc. "It's Hip To Be Square." Newsweek 136.10 (2000): 53. MasterFILE Premier. Web. 23 July 2013.
  3. 1 2 3 4 5 6 "Bringing Indy to N64". IGN. 2000-11-09. Retrieved September 24, 2013.
  4. ↑ "Super Mario Galaxy". Retrieved 2009-01-11.
  5. ↑ "Hidden Surface Removal" (PDF). Archived from the original (PDF) on March 4, 2009. Retrieved April 24, 2014.
  6. ↑ Next Generation, issue 24 (December 1996), page 74
  7. ↑ "Nintendo 64". Archived from the original on 2007-07-10. Retrieved 2009-01-14.
  8. ↑ "Indiana Jones and the Infernal Machine". IGN. December 12, 2000. Retrieved September 24, 2013.
  9. ↑ "Interview: Battling the N64 (Naboo)". IGN64. 2000-11-10. Retrieved 2008-03-27.
  10. ↑ "Difference Between RDRAM and DDR". Retrieved 2009-01-15.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.