BenSkywalker:
Hmm, wow... First of all, you basically don't draw anything on the SNES in standard 2D games like SMW. All you need to do to scroll the entire BG is write to two 16-bit registers and the PPU takes care of what to show. No blitting is done to any framebuffer - the chip decides what color to transmit for every pixel during the scanning, based on the various register settings and the contents of the character RAM (tile data). The same goes for all sprite movement, transparancies, etc.
Basically there's no data transferred over the cartridge bus during actual gameplay, only code. The graphics data needed is usually DMA'd to the internal PPU VRAM before each level, with some additional tile animation and sprites DMA'd during VBlank, when necessary. It is also during every VBlank you update background scrolling and sprite positions.
Believe me, the whole SNES architecture (and practially every other machine up until the 3D era) is built to run in sync with the television raster scanning, where a vertical blanking occurs at a frequency of 60 or 50Hz depending on the region. Actually there are registers that read the current X and Y position of the cathode ray, and the current field if running in interlace mode (I believe only one SNES game ran interlaced though, the non-interlaced ("progressive" if you wish) 256*224@60Hz mode was used almost exclusively). You can even set an interrupt to go off at an excact position of the ray. Put some palette modifying code on the interrupt and you can see the color changing on that position on the screen. The basic principle of having everything to run in perfect sync with the TV is the same on most consoles and home computers up to the early 90s, the SNES just happens to be a good example (and a system I've worked with). Another great example is the "copper" co-processor of the Amiga, it had the sole purpose of keeping track of the television scanning and execute related code.
And btw, 30fps is not smooth, *especially* not with 2D graphics. A basic scrolling 2D background is perhaps the best example of how big a difference there is between 30 and 60 fps movement.
For SMW it is easy to explain why it couldn't run at 60FPS, the SNES and its carts did not have the technical capability of doing so. Unlike a 3D game every frame had to have seperate images already drawn and loaded on to the cart. All of these images had to be pulled from the cart and then displayed, carts did not have the memory to store the kind of data that a game like SMW would require. The other issue for the SNES is bandwith and throughput of the video output system. I suppose it would be possible in a theoretical sense to draw something at 60FPS on the SNES, but not a game with multiple objects moving around. 30FPS is smooth on a console as long as the framerate doesn't fluctuate.
Hmm, wow... First of all, you basically don't draw anything on the SNES in standard 2D games like SMW. All you need to do to scroll the entire BG is write to two 16-bit registers and the PPU takes care of what to show. No blitting is done to any framebuffer - the chip decides what color to transmit for every pixel during the scanning, based on the various register settings and the contents of the character RAM (tile data). The same goes for all sprite movement, transparancies, etc.
Basically there's no data transferred over the cartridge bus during actual gameplay, only code. The graphics data needed is usually DMA'd to the internal PPU VRAM before each level, with some additional tile animation and sprites DMA'd during VBlank, when necessary. It is also during every VBlank you update background scrolling and sprite positions.
Believe me, the whole SNES architecture (and practially every other machine up until the 3D era) is built to run in sync with the television raster scanning, where a vertical blanking occurs at a frequency of 60 or 50Hz depending on the region. Actually there are registers that read the current X and Y position of the cathode ray, and the current field if running in interlace mode (I believe only one SNES game ran interlaced though, the non-interlaced ("progressive" if you wish) 256*224@60Hz mode was used almost exclusively). You can even set an interrupt to go off at an excact position of the ray. Put some palette modifying code on the interrupt and you can see the color changing on that position on the screen. The basic principle of having everything to run in perfect sync with the TV is the same on most consoles and home computers up to the early 90s, the SNES just happens to be a good example (and a system I've worked with). Another great example is the "copper" co-processor of the Amiga, it had the sole purpose of keeping track of the television scanning and execute related code.
And btw, 30fps is not smooth, *especially* not with 2D graphics. A basic scrolling 2D background is perhaps the best example of how big a difference there is between 30 and 60 fps movement.