Hello, and welcome to Killerkirby's Domain! Enjoy.
| razr phone |
skip to main |
skip to sidebar
I'm a big kirby fan. My favourite Kirby game is Kirby's Dreamland. The first kirby game ever. In 1992 Kirby made his debut on the game boy as a white little puffball... instead of a pink little puffball. Kirby's Dream Land, known in Japan as Hoshi no Kirby is a platforming video game developed by HALLaboratory, Inc. and published by Nintendo for the Game Boy handheld video game console. It is both the first video game in the Kirby series and the debut of the Kirby character. It was first released in Japan, and was later released in North America.
Kirby's Dream Land was designed by Masahiro Sakurai, then an employee of HAL Laboratory. Sakurai intended for Kirby's Dream Land to be a simple game that could be played by beginning gamers. As the inaugural Kirby title, Kirby's Dream Land created many conventions that would appear in later games in the series, including Kirby's basic moves. However, Kirby's trademark "copy" ability would not appear until Kirby's Adventure, released less than one year later. He was pink in Kirby's Adventure. And he was in all the games after that too.
The Misc. Blog
Facebook Badge
Click for dancing Diddy Kong
http://www.geocities.com/arielpurkey/diddyjuggleaniou0.gif
Some sites I like:
Shy Guy Kingdom.Sprites:http://tsgk.captainn.net/index.php?p=search&q=Kirby
VGMusic.Midis:http://www.vgmusic.com/
The Mushroom Kingdom.Many Things:http://themushroomkingdom.net/
The Official Kirby Site:http://www.kirbykirbykirby.com/
Kirby's Rainbow Resort:http://kirby.classicgaming.gamespy.com/index2.html
Yoshi Legacy:http://yoshilegacy.co.nr/
These are sites that are very popular and are very useful.So please visit some if not all of these sites.
Some sites I like:
Shy Guy Kingdom.Sprites:http://tsgk.captainn.net/index.php?p=search&q=Kirby
VGMusic.Midis:http://www.vgmusic.com/
The Mushroom Kingdom.Many Things:http://themushroomkingdom.net/
The Official Kirby Site:http://www.kirbykirbykirby.com/
Kirby's Rainbow Resort:http://kirby.classicgaming.gamespy.com/index2.html
Yoshi Legacy:http://yoshilegacy.co.nr/
These are sites that are very popular and are very useful.So please visit some if not all of these sites.
Blog Archive
Contributors
Kirby's Dreamland
I'm a big kirby fan. My favourite Kirby game is Kirby's Dreamland. The first kirby game ever. In 1992 Kirby made his debut on the game boy as a white little puffball... instead of a pink little puffball. Kirby's Dream Land, known in Japan as Hoshi no Kirby is a platforming video game developed by HALLaboratory, Inc. and published by Nintendo for the Game Boy handheld video game console. It is both the first video game in the Kirby series and the debut of the Kirby character. It was first released in Japan, and was later released in North America.
Kirby's Dream Land was designed by Masahiro Sakurai, then an employee of HAL Laboratory. Sakurai intended for Kirby's Dream Land to be a simple game that could be played by beginning gamers. As the inaugural Kirby title, Kirby's Dream Land created many conventions that would appear in later games in the series, including Kirby's basic moves. However, Kirby's trademark "copy" ability would not appear until Kirby's Adventure, released less than one year later. He was pink in Kirby's Adventure. And he was in all the games after that too.
GAMEBOY AND GAMEBOY ADVANCED
Gameboy Advanced:
Size: Approximately 3.2 x 5.69 x 0.97 inches.
Weight: Approximately 140 grams (5 ounces).
Screen: 2.9 inches reflective thin-film transistor (TFT) color LCD.
Power: 2 AA batteries.
Battery Life: Approximately 20 hours (using alkaline batteries).
CPU: 16.8 MHz 32-bit ARM7TDMI with embedded memory.
Memory: 32 kilobyte + 96 kilobyte VRAM (internal to the CPU), 256 kilobyte WRAM (external to the CPU).
Resolution: 240 x 160 pixels.
Color support: 15-bit RGB (16-bit color space using 5 bits depth per channel), capable of displaying 512 simultaneous colors in "character mode" and 32,768 simultaneous colors in "bitmap mode".
Backward compatibility for Game Boy and Game Boy Color games is provided by a 8.4MHz Z80 co-processor, while a link port at the top of the unit allows it to be connected to other devices via use of a Nintendo Game Link cable or GameCube cable.
Gameboy:
CPU
Custom 8-bit Sharp x80 core at 4.194304 MHz which is similar to an Intel8080 in that all of the registers introduced in the Z80 are not present. However, some of the instruction set enhancements from the Z80, particularly bit manipulation are present. Still other instructions are unique to this particular flavor of x80 CPU. The core also contains integrated sound generation
RAM
8 kByte internal S-RAM
Video RAM
8 kByte internal
ROM
256 kbit, 512 kbit, 1 Mbit, 2 Mbit and 4 Mbit and 8 Mbit cartridges
Sound
2 Square Waves, 1 voluntary Wave (Triangle/DPCM), 1 White noise. The unit only has one speaker, but headphones provide stereo sound
Display
Reflective LCD 160 × 144 pixels
Screen Size
66 mm (2.6 in) diagonal
Color Palette
4 shades of "gray" (green to (very) dark blue)
Communication
Up to 16 Game Boys can be linked together via serial ports
Power
6 V, 0.7 W (4 AA batteries provide ~#35 hours)
Dimensions
90mm(W) × 148mm(H) × 32mm(D)/3.5 × 5.8 × 1.3 (inch)
Size: Approximately 3.2 x 5.69 x 0.97 inches.
Weight: Approximately 140 grams (5 ounces).
Screen: 2.9 inches reflective thin-film transistor (TFT) color LCD.
Power: 2 AA batteries.
Battery Life: Approximately 20 hours (using alkaline batteries).
CPU: 16.8 MHz 32-bit ARM7TDMI with embedded memory.
Memory: 32 kilobyte + 96 kilobyte VRAM (internal to the CPU), 256 kilobyte WRAM (external to the CPU).
Resolution: 240 x 160 pixels.
Color support: 15-bit RGB (16-bit color space using 5 bits depth per channel), capable of displaying 512 simultaneous colors in "character mode" and 32,768 simultaneous colors in "bitmap mode".
Backward compatibility for Game Boy and Game Boy Color games is provided by a 8.4MHz Z80 co-processor, while a link port at the top of the unit allows it to be connected to other devices via use of a Nintendo Game Link cable or GameCube cable.
Gameboy:
CPU
Custom 8-bit Sharp x80 core at 4.194304 MHz which is similar to an Intel8080 in that all of the registers introduced in the Z80 are not present. However, some of the instruction set enhancements from the Z80, particularly bit manipulation are present. Still other instructions are unique to this particular flavor of x80 CPU. The core also contains integrated sound generation
RAM
8 kByte internal S-RAM
Video RAM
8 kByte internal
ROM
256 kbit, 512 kbit, 1 Mbit, 2 Mbit and 4 Mbit and 8 Mbit cartridges
Sound
2 Square Waves, 1 voluntary Wave (Triangle/DPCM), 1 White noise. The unit only has one speaker, but headphones provide stereo sound
Display
Reflective LCD 160 × 144 pixels
Screen Size
66 mm (2.6 in) diagonal
Color Palette
4 shades of "gray" (green to (very) dark blue)
Communication
Up to 16 Game Boys can be linked together via serial ports
Power
6 V, 0.7 W (4 AA batteries provide ~#35 hours)
Dimensions
90mm(W) × 148mm(H) × 32mm(D)/3.5 × 5.8 × 1.3 (inch)
NINTENDO 64
The nintendo 64 was the first 64-bit system ever made at the time.The CPU powering Nintendo 64 is a MIPS R4300i-based NEC VR4300. The CPU is clocked at 93.75 MHz and connects to the rest of the system through a 32-bit data bus. VR43045 is a RISC 5-stage scalar in-order execution processor with an integrated floating point unit. It is a 64-bit processor, in that it has 64-bit registers a 64-bit instruction set, and 64-bit internal data paths. However, the cost-reduced NEC VR4300 CPU utilized in the console only has 32-bit buses whereas more powerful MIPS CPUs are equipped with 64-bit buses. Many games took advantage of the chip's 32-bit processing mode as the greater data precision available with 64-bit data types is not typically required by 3D games. Also 64-bit data uses twice as much RAM, cache, and bandwidth thereby reducing the overall system performance. This was later taken advantage of by emulators such as the UltraHLE and Project64 that had to run on 32-bit Intel systems. These emulators performed most calculations at 32-bit precision, and trapped the few OS subroutines that actually made use of 64-bit instructions.
The CPU has an internal 32 KiB L1 cache but no L2 cache. It was built by NEC on a 0.35 µm process and consisted of 4.6 million transistors. The CPU is cooled passively by an aluminum heatspreader that makes contact with a steel heat sink above.
Nintendo 64's graphics and audio duties are performed by the 64-bit SGI co-processor, named the "Reality Co-Processor". The RCP is a 62.5 MHz chip split internally into two major components, the "Reality Drawing Processor" (RDP) and the "Reality Signal Processor" (RSP). Each area communicates with the other by way of a 128-bit internal data bus that provides 1.0 GB/s bandwidth. The RSP is a MIPS R4000-based 8-bit integer vector processor. It is programmable through microcode, allowing the chip's functions to be significantly altered if necessary, to allow for different types of work, precision, and workloads.[8] The RSP performs transform, clipping and lighting calculations, triangle setup.
The RSP, as said, also frequently performs audio functions (although the CPU can be tasked with this as well). It can playback virtually any type of audio (dependent on software codecs) including uncompressed PCM, MP3, MIDI, and tracker music. The RSP is capable of a maximum of 100 channels of PCM at a time, but this is with 100% system utilization for audio. It has a maximum sampling rate of 48 kHz with 16-bit audio. However, storage limitations caused by the cartridge format limited audio size (and thus quality).
The RDP is the machine's rasterizer and performs the bulk of actual image creation before output to the display. Nintendo 64 has a maximum color depth of 16.8 million colors (32,768 on-screen) and can display a resolution range of 256 × 224 to 640 × 480 pixels.
RCP 3D features:
Z-buffering
Anti-aliasing
Texture mapping
Bilinear filtering
Mip-mapping
Trilinear mip-map interpolation (filters mip-maps and textures smoothly without blockiness). Nintendo 64's filtering is not entirely accurate. Precision was reduced to lower mathematical demands.[9]
Perspective-correct texture mapping (keeps textures from "warping" when viewed at different angles).[10]
Environment mapping
Gouraud shading, Level of Detail (LOD)
Fillrate: ~30 megapixels/sec with Z-buffering enabled.[11]
The RCP also provides the CPU's access to main system memory via a 250 MB/s bus. Unfortunately, this link does not allow direct memory access for the CPU. The RCP is cooled passively by an aluminum heatspreader that makes contact with a steel heat sink above.
The final major component in the system is the RAM. Nintendo 64 was the first console to implement a unified memory subsystem, instead of having separate banks of memory for CPU, audio, and video, for example. The memory itself consists of 4 MiB of RAMBUS RDRAM (expandable to 8 MiB) with a 9-bit data bus at 500 MHz providing the system with 562.5 MB/s peak bandwidth. RAMBUS was quite new at the time and offered Nintendo a way to provide a large amount of bandwidth for a relatively low cost. The narrow bus makes board design easier and cheaper than the higher width data buses required for high bandwidth out of slower-clocked RAM types (such as VRAM or EDO DRAM). However RDRAM, at the time, came with a very high access latency, and this did cause some grief for the game developers and limited hardware performance.
Nintendo 64 games were cartridge-based. Cartridge size varied from a tiny 4 MiB (32 Mbit) (i.e., Automobili Lamborghini) to 64 MiB (512 Mbit) for Resident Evil 2. The cartridge dimensions were 10.23 × 7.48 × 2.87 inches (260 × 190 × 73 mm) W×D×H. Some of the cartridges included internal EEPROM or battery-backed-up RAM for saved game storage. Otherwise game saves were put onto separate memory cards.
The new controller included with Nintendo 64 consisted of 1 analog stick, 2 shoulder buttons, 1 digital cross pad, 6 face buttons, a 'start' button, and one digital trigger (Z). It beat the Sega Saturn's analog controller to market by approximately one month.
[edit] Architecture and software development
The central processing unit (CPU) was primarily used for game logic, such as input management, some audio, and AI, while the "reality co-processor" (RCP) did everything else. The RCP was a customized processor that performed the majority of audio and visual tasks within the Nintendo 64. The chip is split into two main units, the "reality drawing processor" (RDP) and the "reality signal processor" (RSP). It also provides the system's interface with the RDRAM. The RDP component basically just read a FIFO buffer and rasterized polygons. The RSP was a DSP, based around a MIPS R4000 core, designed to work with 8-bit integer vector operations.[8]
In a typical N64 game, the RSP would do transforms, lighting, clipping, triangle setup, and some of the audio decoding.[8] Nintendo 64 was one of the few consoles without a dedicated audio chip so these tasks fell on the RSP and/or CPU. It was relatively common to do audio on the main CPU to increase the graphics performance.[8] Workload on the Nintendo 64 could be arranged almost in any way the programmer saw fit. This created a system that was quite flexible and malleable to the game's needs, but it also assumed the programmer would be able to properly profile the code to optimize usage of each part of the machine.
The RSP was completely programmable, through microcode (µcode). By altering the microcode run on the device, it could perform different operations, create new effects, and be better tuned for speed or quality. However, Nintendo was unwilling to share the microcode tools with developers until the end of the Nintendo 64's life-cycle. Programming RSP microcode was said to be quite difficult because the Nintendo 64 µcode tools were very basic, with no debugger, and poor documentation. As a result, it was very easy to make mistakes that would be hard to track down; mistakes that could cause seemingly random bugs or glitches. Some developers noted that the default SGI microcode ("Fast3D") was actually quite poorly profiled for use in games (it was too accurate), and performance suffered as a result. Several companies were able to create custom microcode programs that ran their software far better than SGI's generic software (e.g., Factor 5, Boss Game Studios, and Rare).
Two of the SGI microcodes[8][12]
Fast3D microcode: < ~100,000 polygons per second
Turbo3D microcode: 500,000–600,000 polygons per second with lower quality. Nintendo never allowed this code to be used in shipping games.
Conker's superior texturing
The Nintendo 64 had some weaknesses that were caused by a combination of oversight on the part of the hardware designers, limitations on 3D technology of the time, and manufacturing capabilities. One major flaw was the limited texture cache of 4 KiB.[12] This made it extremely difficult to load anything but small textures into the rendering engine, especially textures with high color depth, and was the primary cause of blurry graphics. The small texture limitation caused blurring because developers would stretch these small textures to cover a surface and then the console's bilinear filtering would blur them even more. To make matters worse, because of how the renderer was designed, if mipmapping was used the texture cache was effectively halved to 2 KiB. To put this in perspective, this cache could be quickly filled with even small textures (a 64×64 4-bit/pixel (bpp) texture is 2 KiB and a 128×64 4 bpp texture is 4 KiB). Modern video cards and consoles (2006) frequently deal with 1024 x 1024 8 bpp and larger textures, and have a more flexible texture cache (not always larger). Towards the end of Nintendo 64's lifetime, creative developers managed to use tricks such as multi-layered texturing and heavily-clamped small texture pieces to simulate larger textures. Conker's Bad Fur Day is possibly the best example of this ingenuity. Games would often also use plain colored Gouraud shading instead of texturing on some surfaces, especially in games with themes not targeting realism (e.g., Super Mario 64).
There were other challenges for developers to work around. Z-buffering significantly crippled the RDP's fillrate.[8] Thus, for maximum performance, managing the z-depth of objects, so things would appear in the right order and not on top of each other, was put on the programmer instead of the hardware. Most Nintendo 64 games were actually fill-rate limited, not geometry limited, which is ironic considering the great concern for Nintendo 64's low ~100,000 polygon per second rating during its time. In fact, World Driver Championship was one of the most polygon-intense Nintendo 64 games and frequently would push past Sony PlayStation's typical in-game polygon counts. This game also used custom microcode to improve the RSP's capabilities.
The unified memory subsystem of Nintendo 64 was another critical weakness for the machine. The RDRAM had very high access latency and this mostly canceled out its high bandwidth advantage. A high latency memory subsystem creates delays in how fast the processors can get the data they need, and how fast they can alter this data. Game developers also said that the Nintendo 64's memory controller setup was fairly poor, and this magnified the situation somewhat. The R4300 CPU was the worst off component because it had to go through the RCP to access main memory, and could not use DMA (the RCP could) to do so, so its RAM access performance was quite poor. There was no memory prefetch or read under write functionality either.
Despite these drawbacks, the Nintendo 64 hardware was architecturally superior to the PlayStation.[13] It was, however, more challenging to program and thus difficult to reach peak performance/quality.
Battle for Naboo's draw distance
One of the best examples of rewritten µcode on Nintendo 64 was Factor 5's N64 conversion of the Indiana Jones and the Infernal Machine PC game. In this game the Factor 5 team decided they wanted the game to run in high resolution mode (640×480) because of how much they liked the crispness it added. The machine was taxed to the limit running at 640×480 though, so they absolutely needed to scrape every last bit of performance they could out of Nintendo 64. Firstly, the Z-buffer could not be used because it alone consumed a huge amount of the console's texture fillrate. To work around the 4 KiB texture cache the programmers came up with custom texture formats and tools to help the artists make the best possible textures. The tool would analyze each texture and try to choose the best texture format to work with the machine and look as good as possible. They took advantage of the cartridge as a texture streaming source to squeeze as much detail into each environment, and work around RAM limitations. They wrote microcode for real-time lighting, because the SGI code was poor for this task, and they wanted to have even more lighting than the PC version had used. Factor 5's microcode allowed almost unlimited real-time lighting, and significantly boosted the polygon count. In the end, the game was more feature-filled than the PC version (quite a feat) and unsurprisingly, was one of the most advanced games for Nintendo 64.[14]
Factor 5 also showed ingenuity with their Star Wars games, Star Wars: Rogue Squadron and Star Wars: Battle for Naboo, where their team again used custom microcode. In Star Wars: Rogue Squadron the team tweaked the microcode for a landscape engine to create the alien worlds. Then for Star Wars: Battle for Naboo they took what they learned from Rogue Squadron and pushed the machine even farther to make the game run at 640×480, and implement enhancements for both particles and the landscape engine. Battle for Naboo enjoyed an impressive draw distance and large amounts of snow and rain even with the high resolution, thanks to their efforts.
The CPU has an internal 32 KiB L1 cache but no L2 cache. It was built by NEC on a 0.35 µm process and consisted of 4.6 million transistors. The CPU is cooled passively by an aluminum heatspreader that makes contact with a steel heat sink above.
Nintendo 64's graphics and audio duties are performed by the 64-bit SGI co-processor, named the "Reality Co-Processor". The RCP is a 62.5 MHz chip split internally into two major components, the "Reality Drawing Processor" (RDP) and the "Reality Signal Processor" (RSP). Each area communicates with the other by way of a 128-bit internal data bus that provides 1.0 GB/s bandwidth. The RSP is a MIPS R4000-based 8-bit integer vector processor. It is programmable through microcode, allowing the chip's functions to be significantly altered if necessary, to allow for different types of work, precision, and workloads.[8] The RSP performs transform, clipping and lighting calculations, triangle setup.
The RSP, as said, also frequently performs audio functions (although the CPU can be tasked with this as well). It can playback virtually any type of audio (dependent on software codecs) including uncompressed PCM, MP3, MIDI, and tracker music. The RSP is capable of a maximum of 100 channels of PCM at a time, but this is with 100% system utilization for audio. It has a maximum sampling rate of 48 kHz with 16-bit audio. However, storage limitations caused by the cartridge format limited audio size (and thus quality).
The RDP is the machine's rasterizer and performs the bulk of actual image creation before output to the display. Nintendo 64 has a maximum color depth of 16.8 million colors (32,768 on-screen) and can display a resolution range of 256 × 224 to 640 × 480 pixels.
RCP 3D features:
Z-buffering
Anti-aliasing
Texture mapping
Bilinear filtering
Mip-mapping
Trilinear mip-map interpolation (filters mip-maps and textures smoothly without blockiness). Nintendo 64's filtering is not entirely accurate. Precision was reduced to lower mathematical demands.[9]
Perspective-correct texture mapping (keeps textures from "warping" when viewed at different angles).[10]
Environment mapping
Gouraud shading, Level of Detail (LOD)
Fillrate: ~30 megapixels/sec with Z-buffering enabled.[11]
The RCP also provides the CPU's access to main system memory via a 250 MB/s bus. Unfortunately, this link does not allow direct memory access for the CPU. The RCP is cooled passively by an aluminum heatspreader that makes contact with a steel heat sink above.
The final major component in the system is the RAM. Nintendo 64 was the first console to implement a unified memory subsystem, instead of having separate banks of memory for CPU, audio, and video, for example. The memory itself consists of 4 MiB of RAMBUS RDRAM (expandable to 8 MiB) with a 9-bit data bus at 500 MHz providing the system with 562.5 MB/s peak bandwidth. RAMBUS was quite new at the time and offered Nintendo a way to provide a large amount of bandwidth for a relatively low cost. The narrow bus makes board design easier and cheaper than the higher width data buses required for high bandwidth out of slower-clocked RAM types (such as VRAM or EDO DRAM). However RDRAM, at the time, came with a very high access latency, and this did cause some grief for the game developers and limited hardware performance.
Nintendo 64 games were cartridge-based. Cartridge size varied from a tiny 4 MiB (32 Mbit) (i.e., Automobili Lamborghini) to 64 MiB (512 Mbit) for Resident Evil 2. The cartridge dimensions were 10.23 × 7.48 × 2.87 inches (260 × 190 × 73 mm) W×D×H. Some of the cartridges included internal EEPROM or battery-backed-up RAM for saved game storage. Otherwise game saves were put onto separate memory cards.
The new controller included with Nintendo 64 consisted of 1 analog stick, 2 shoulder buttons, 1 digital cross pad, 6 face buttons, a 'start' button, and one digital trigger (Z). It beat the Sega Saturn's analog controller to market by approximately one month.
[edit] Architecture and software development
The central processing unit (CPU) was primarily used for game logic, such as input management, some audio, and AI, while the "reality co-processor" (RCP) did everything else. The RCP was a customized processor that performed the majority of audio and visual tasks within the Nintendo 64. The chip is split into two main units, the "reality drawing processor" (RDP) and the "reality signal processor" (RSP). It also provides the system's interface with the RDRAM. The RDP component basically just read a FIFO buffer and rasterized polygons. The RSP was a DSP, based around a MIPS R4000 core, designed to work with 8-bit integer vector operations.[8]
In a typical N64 game, the RSP would do transforms, lighting, clipping, triangle setup, and some of the audio decoding.[8] Nintendo 64 was one of the few consoles without a dedicated audio chip so these tasks fell on the RSP and/or CPU. It was relatively common to do audio on the main CPU to increase the graphics performance.[8] Workload on the Nintendo 64 could be arranged almost in any way the programmer saw fit. This created a system that was quite flexible and malleable to the game's needs, but it also assumed the programmer would be able to properly profile the code to optimize usage of each part of the machine.
The RSP was completely programmable, through microcode (µcode). By altering the microcode run on the device, it could perform different operations, create new effects, and be better tuned for speed or quality. However, Nintendo was unwilling to share the microcode tools with developers until the end of the Nintendo 64's life-cycle. Programming RSP microcode was said to be quite difficult because the Nintendo 64 µcode tools were very basic, with no debugger, and poor documentation. As a result, it was very easy to make mistakes that would be hard to track down; mistakes that could cause seemingly random bugs or glitches. Some developers noted that the default SGI microcode ("Fast3D") was actually quite poorly profiled for use in games (it was too accurate), and performance suffered as a result. Several companies were able to create custom microcode programs that ran their software far better than SGI's generic software (e.g., Factor 5, Boss Game Studios, and Rare).
Two of the SGI microcodes[8][12]
Fast3D microcode: < ~100,000 polygons per second
Turbo3D microcode: 500,000–600,000 polygons per second with lower quality. Nintendo never allowed this code to be used in shipping games.
Conker's superior texturing
The Nintendo 64 had some weaknesses that were caused by a combination of oversight on the part of the hardware designers, limitations on 3D technology of the time, and manufacturing capabilities. One major flaw was the limited texture cache of 4 KiB.[12] This made it extremely difficult to load anything but small textures into the rendering engine, especially textures with high color depth, and was the primary cause of blurry graphics. The small texture limitation caused blurring because developers would stretch these small textures to cover a surface and then the console's bilinear filtering would blur them even more. To make matters worse, because of how the renderer was designed, if mipmapping was used the texture cache was effectively halved to 2 KiB. To put this in perspective, this cache could be quickly filled with even small textures (a 64×64 4-bit/pixel (bpp) texture is 2 KiB and a 128×64 4 bpp texture is 4 KiB). Modern video cards and consoles (2006) frequently deal with 1024 x 1024 8 bpp and larger textures, and have a more flexible texture cache (not always larger). Towards the end of Nintendo 64's lifetime, creative developers managed to use tricks such as multi-layered texturing and heavily-clamped small texture pieces to simulate larger textures. Conker's Bad Fur Day is possibly the best example of this ingenuity. Games would often also use plain colored Gouraud shading instead of texturing on some surfaces, especially in games with themes not targeting realism (e.g., Super Mario 64).
There were other challenges for developers to work around. Z-buffering significantly crippled the RDP's fillrate.[8] Thus, for maximum performance, managing the z-depth of objects, so things would appear in the right order and not on top of each other, was put on the programmer instead of the hardware. Most Nintendo 64 games were actually fill-rate limited, not geometry limited, which is ironic considering the great concern for Nintendo 64's low ~100,000 polygon per second rating during its time. In fact, World Driver Championship was one of the most polygon-intense Nintendo 64 games and frequently would push past Sony PlayStation's typical in-game polygon counts. This game also used custom microcode to improve the RSP's capabilities.
The unified memory subsystem of Nintendo 64 was another critical weakness for the machine. The RDRAM had very high access latency and this mostly canceled out its high bandwidth advantage. A high latency memory subsystem creates delays in how fast the processors can get the data they need, and how fast they can alter this data. Game developers also said that the Nintendo 64's memory controller setup was fairly poor, and this magnified the situation somewhat. The R4300 CPU was the worst off component because it had to go through the RCP to access main memory, and could not use DMA (the RCP could) to do so, so its RAM access performance was quite poor. There was no memory prefetch or read under write functionality either.
Despite these drawbacks, the Nintendo 64 hardware was architecturally superior to the PlayStation.[13] It was, however, more challenging to program and thus difficult to reach peak performance/quality.
Battle for Naboo's draw distance
One of the best examples of rewritten µcode on Nintendo 64 was Factor 5's N64 conversion of the Indiana Jones and the Infernal Machine PC game. In this game the Factor 5 team decided they wanted the game to run in high resolution mode (640×480) because of how much they liked the crispness it added. The machine was taxed to the limit running at 640×480 though, so they absolutely needed to scrape every last bit of performance they could out of Nintendo 64. Firstly, the Z-buffer could not be used because it alone consumed a huge amount of the console's texture fillrate. To work around the 4 KiB texture cache the programmers came up with custom texture formats and tools to help the artists make the best possible textures. The tool would analyze each texture and try to choose the best texture format to work with the machine and look as good as possible. They took advantage of the cartridge as a texture streaming source to squeeze as much detail into each environment, and work around RAM limitations. They wrote microcode for real-time lighting, because the SGI code was poor for this task, and they wanted to have even more lighting than the PC version had used. Factor 5's microcode allowed almost unlimited real-time lighting, and significantly boosted the polygon count. In the end, the game was more feature-filled than the PC version (quite a feat) and unsurprisingly, was one of the most advanced games for Nintendo 64.[14]
Factor 5 also showed ingenuity with their Star Wars games, Star Wars: Rogue Squadron and Star Wars: Battle for Naboo, where their team again used custom microcode. In Star Wars: Rogue Squadron the team tweaked the microcode for a landscape engine to create the alien worlds. Then for Star Wars: Battle for Naboo they took what they learned from Rogue Squadron and pushed the machine even farther to make the game run at 640×480, and implement enhancements for both particles and the landscape engine. Battle for Naboo enjoyed an impressive draw distance and large amounts of snow and rain even with the high resolution, thanks to their efforts.
NES
NES:the NES (nintendo entertainment system) is the first nintendo system ever! It was made in 1983. Here are some facts:
For its CPU, the NES uses an 8-bit microprocessor produced by Ricoh based on a MOS Technology 6502 core. It incorporates custom sound hardware and a restricted DMA controller on-die. NTSC (North America and Japan) versions of the console use the Ricoh 2A03 (or RP2A03), which runs at 1.79 MHz. PAL (Europe and Australia) versions of console utilize the Ricoh 2A07 (or RP2A07), which is identical to the 2A03 save for the fact that it runs at a slower 1.66 MHz clock rate.
For its CPU, the NES uses an 8-bit microprocessor produced by Ricoh based on a MOS Technology 6502 core. It incorporates custom sound hardware and a restricted DMA controller on-die. NTSC (North America and Japan) versions of the console use the Ricoh 2A03 (or RP2A03), which runs at 1.79 MHz. PAL (Europe and Australia) versions of console utilize the Ricoh 2A07 (or RP2A07), which is identical to the 2A03 save for the fact that it runs at a slower 1.66 MHz clock rate.
No comments:
Post a Comment