Why NES Games are Insane
May 17th 2008 23:09
Into the Beast
NES games, back in the day, had rather convoluted glitches, and some other weird behaviors like slowdown and graphical flickers. Something you have to understand about an NES is that it has horrendous technical limitations, the likes of which seem almost unimaginable when compared to, say, modern PCs. So let us gloriously explore!
By the Numbers
The NES is capable of, numerically...
Running at 1.97 Mhz with 2kb of RAM, with the ability to read up to 64kb of ROM/RAM at any time.
The ability to display up to 8 sprites per scanline (so there can only be 8 total sprites on any horizontal line of the screen), 12 sprite and 13 background colors onscreen out of a palette of 64, with a separate Picture Processing Unit to render graphics without overtaxing the horribly weak CPU, and its own Video RAM of 2kb.
Compare that to a modern PC with gigabytes/gigahertz of RAM and power, and you can begin to see just how limited a platform the NES really was.
So. What Does this Actually Mean?
The limitations of the NES inspired a number of inventive fixes to the gross problems this causes to programmers. First of all, they had to program directly in processor assembly, because the system didn't have enough RAM to even handle a higher-level programming language (To those not savvy to that, I mean like C /Java kinds of languages.). Secondly, the processor is so slow that there actually need to be some workarounds to ensure it still has enough time to process everything without glitching up. Finally, the same goes for the PPU, which often depends on specific times during the display of frames.
Often, one of the side-effects of these limitations is making a lot of shortcuts - if you recall the weird warpzone code in Super Mario Brothers, it checked for the warpzone based on world number, then on the level type. By not having to look up a separate warpzone table, this saves a little bit of memory by not having to load any more data than what is already loaded (the level data). Of course, we all know what this shortcut ends up doing.
Other things that happen include pre-programmed slowdown and flickering. The NES itself, were it to have an instruction that takes longer than 1/60 of a second to do (thus the length of a frame, in time), it would normally glitch up due to trying to load the next frame with instructions left undone. So instead, a slowdown is performed, by forcing the NES to not load the next frame's worth of actions, so it can finish processing - and repeating a frame gives the effect of everything slowing down. Flickering, on the other hand, is simply a fix for the 8 sprites per scanline limitation, which simply remembers where sprites are, and decides to alternate between sprites over the limit, rendering one one frame, and the other the next, so they flicker between frames to ensure that there are still only 8 sprites per horizontal scanline, even if the player, who can't possibly see each individual frame, sees more than that due to flickering.
All of this trickery goes a lot to explain the reason why some NES games tend to unravel if the player does really odd things - because they are difficult to program clearly, and require a lot of compression and memory optimization to use. But even if this opens holes when the attempts to optimize memory use end up neglect some intended limit on the player, it is still ultimately impressive. What an NES is capable of isn't much, and yet the games were in many ways above and beyond the prior game consoles in complexity.
So perhaps this might be somewhat informative, no?
NES games, back in the day, had rather convoluted glitches, and some other weird behaviors like slowdown and graphical flickers. Something you have to understand about an NES is that it has horrendous technical limitations, the likes of which seem almost unimaginable when compared to, say, modern PCs. So let us gloriously explore!
By the Numbers
The NES is capable of, numerically...
Running at 1.97 Mhz with 2kb of RAM, with the ability to read up to 64kb of ROM/RAM at any time.
The ability to display up to 8 sprites per scanline (so there can only be 8 total sprites on any horizontal line of the screen), 12 sprite and 13 background colors onscreen out of a palette of 64, with a separate Picture Processing Unit to render graphics without overtaxing the horribly weak CPU, and its own Video RAM of 2kb.
Compare that to a modern PC with gigabytes/gigahertz of RAM and power, and you can begin to see just how limited a platform the NES really was.
So. What Does this Actually Mean?
The limitations of the NES inspired a number of inventive fixes to the gross problems this causes to programmers. First of all, they had to program directly in processor assembly, because the system didn't have enough RAM to even handle a higher-level programming language (To those not savvy to that, I mean like C /Java kinds of languages.). Secondly, the processor is so slow that there actually need to be some workarounds to ensure it still has enough time to process everything without glitching up. Finally, the same goes for the PPU, which often depends on specific times during the display of frames.
Often, one of the side-effects of these limitations is making a lot of shortcuts - if you recall the weird warpzone code in Super Mario Brothers, it checked for the warpzone based on world number, then on the level type. By not having to look up a separate warpzone table, this saves a little bit of memory by not having to load any more data than what is already loaded (the level data). Of course, we all know what this shortcut ends up doing.
Other things that happen include pre-programmed slowdown and flickering. The NES itself, were it to have an instruction that takes longer than 1/60 of a second to do (thus the length of a frame, in time), it would normally glitch up due to trying to load the next frame with instructions left undone. So instead, a slowdown is performed, by forcing the NES to not load the next frame's worth of actions, so it can finish processing - and repeating a frame gives the effect of everything slowing down. Flickering, on the other hand, is simply a fix for the 8 sprites per scanline limitation, which simply remembers where sprites are, and decides to alternate between sprites over the limit, rendering one one frame, and the other the next, so they flicker between frames to ensure that there are still only 8 sprites per horizontal scanline, even if the player, who can't possibly see each individual frame, sees more than that due to flickering.
All of this trickery goes a lot to explain the reason why some NES games tend to unravel if the player does really odd things - because they are difficult to program clearly, and require a lot of compression and memory optimization to use. But even if this opens holes when the attempts to optimize memory use end up neglect some intended limit on the player, it is still ultimately impressive. What an NES is capable of isn't much, and yet the games were in many ways above and beyond the prior game consoles in complexity.
So perhaps this might be somewhat informative, no?
| 46 |
| Vote |
Subscribe to this blog
Comment by Harry
World Art
Sydney Diary
Personals
Video Games
Brisbane Diarystar
Zoo Parent
Comment by jon
Orble News
Urban Hint
Blog Adviser
Jon's Bookmarks
Debate Battle
Orblepedia
Orble Notes
Sydney WeekendNotes
You may also need to add the email address admin -at- orblemail.com to your address book in order to receive Orble admin emails in the future.
Thanks,
Jon.
(Orble Admin)