-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
-
We have made minor adjustments to how the search bar works on ResetEra. You can read about the changes here.
14 games that pushed the limits of the SNES
- Thread starter Windrunner
- Start date
1st page already have Terranigma, Bahamut Lagoon and Super Aleste!
Like please let me something to say yall!
Playing all these games on hardware is always quite a treat!
I just realized how shitty the PAL version of Stunt Race Fx is compared to the Jpn version, it's incredible.
My fav is (and always will be) Seiken 3.
I don't care that the game is buggier than most Bethesa releases, it's still maddeningly impressive and great to play.
Like please let me something to say yall!
Playing all these games on hardware is always quite a treat!
I just realized how shitty the PAL version of Stunt Race Fx is compared to the Jpn version, it's incredible.
My fav is (and always will be) Seiken 3.
I don't care that the game is buggier than most Bethesa releases, it's still maddeningly impressive and great to play.
Nah, limitations are farther is all.
Look up the wizardry that goes into making some games like BotW on a freaking WiiU or TLoU on a ps3, they had to work with the limitations to make the games work smoothly.
Counting the number of colors a super NES game uses on screen is rather tough because of the different types of video modes the SNES has at it's disposal, and how things like transparency works. For things like the title screen to Donkey Kong Country, it uses mode 3 for the static image. This allows the SNES to have two background layers -- one that can access 256 colors in the palette, and a second that can only access 16 colors in the palette. This lets the bitmap image of Donkey Kong and friends use high color, while the second background layer actually goes unused.
For gameplay, the SNES uses mode 1 while playing. Mode 1 gives the SNES 3 background layers plus 1 sprite layer (In some circles, this would be called "4 layers"). Backgrounds 1 and 2 can only use 16 colors at a time. Background layer 1 is the actual level layout, the ground and platforms you jump on, which usually include a bit of scenery that can't be interacted with:
Background layer 2 is the middle background, which can use an entirely different set of 16 colors:
The far background can only use 4 colors at a time, again, different than the other two sets of 16 colors:
This third background layer is, in most games, used as a window layer, for things like the status bar in Super Mario World. Donkey Kong Country uses sprites that vanish for its status bar, which lets it devote an entire 4 color background layer to special effects. In the early jungle stages, that background layer is pushed far back to create the additional scrolling layers in the far background.
Now, mind you -- these color limitations -- 16 colors for BG1, 16 colors for BG2, and 4 colors for BG3, are per scanline. You are limited to those colors in a horizontal sweep of the raster beam from the TV. When the beam finishes drawing a horizontal line, it sends an interrupt to the CPU called HBLANK, which lets the CPU know that it's done drawing for a second and thus HDMA is open. The CPU, using HDMA, during this time, can change color registers to shift which sets of 16 or 4 colors are being used by these layers, so the next horizontal beam, they can use a different set of colors. HDMA is not unlimited, however, and there is a time constraint -- the beam will eventually reach the left hand side of the screen and begin drawing again, and thus HBLANK will be over and the HDMA window closed. So realistically, only a few colors can be changed per scanline. The far background in the Jungle does this, that's how I described them making the gradient effect. So the far background is 4 colors per horizontal line, by about 30 vertical rows, which translates into about 120 colors for that background.
What makes determining how many colors are on screen at once tough is that, occasionally, the a background layer will be devoted to a mask for color addition or subtraction -- transparency in other words. Transparency on the SNES works by taking two layers and doing math on them -- either adding one layer's colors to the other, or subtracting one layer's color to the other, or averaging the two. DKC uses this a lot for lighting effects. For example:
The green light in this picture is actually a background layer, shaped sort of like this:
which is added to the scene over the other background layers. Using layers as additive or subtractive masks shifts the number of colors on screen by whatever resultant amount color math adds up to. Levels like the crystal levels have shining light graphics as a mask, levels like the under water levels have a goopy wavey water graphic as a mask and so forth.
I actually doubt DKC shows more than 256 colors on one screen, much less 4096, but who knows. It does push a lot of colors on screen at once, though, more than a normal SNES games, thanks to HDMA and smart color math.
The reason I ask is because of this article.
http://www.racketboy.com/retro/super-nintendo-snes-games-that-pushed-the-limits-graphics-soun
It's written by a programmer. It's the first time I heard the game using more the 256 colors, but it sorta made sense because it looked way too good.
Well, that article pushes it off as heresay as well, and I've written for Racketboy myself and there isn't actually a huge editorial staff or anything to fact check. They claim that it uses the same scanline trick I describe to display more than 256 colors, but the only screens in the game that I know displays 256 colors don't use scanline tricks.
I know for a fact using HDMA it displays more colors than normal in gameplay, but I very much doubt it ever displays 4096 colors at once, even more than 256 colors at once.
I'm sure DKC3 taxed the SNES more than the first game, but the first game was the game that blew me away. Honestly the trilogy should probably be lumped together.
i came into this thread to mention R-Type III: The Third Lightning
however,
ive never heard of this game but it is far and away the answer. This is fuckin' incredible!
however,
I can't imagine that any other game pushed the sfc more than rendering ranger. ok, maybe Super Aleste.
there are times you can't even see the (multi-parallax and animated) backgrounds in the shmup sections because of all the bullets, explosions and enemies on screen at once. without slowdown and flicker.
also no additional booster chip needed
There was a super interesting interview with Manfred Trenz in a magazine how he made it possible and overcame the bottle neck in the SFC hardware.
even the 2nd one afair
ive never heard of this game but it is far and away the answer. This is fuckin' incredible!
What an amazing post thanks man!I hate when people say this, they come off like they're so jaded and so incredibly wrong. Like they don't want to look foolish for being impressed by the prerendered graphics, that they ignore all the things that Donkey Kong Country does, either because they don't have a technical eye or because they flat out don't know what it does behind the hood. Most of the things people are impressed about in this topic are the result of dedicated co-processors on the cartridge, which honestly does not impress me. Donkey Kong Country, however, is filled to the brim with unusual graphical techniques on the SNES that really push the hardware extremely hard, all without special chips.
Let's take a quick look, for example. Firstly, let's talk about the games "just being prerendered art." Prerendered art on these old machines is actually something extremely hard to pull of. Lots of other games from other developers, both on the SNES and its competitors, tried pre-rendered art on their games, and they don't look anywhere near as great as Donkey Kong Country. This is because of a lot of techniques DKC used exclusively that other SNES games didn't take advantage of. It's not merely a process of spitting the sprite through a conversion process and plopping it into a game. The big problem with trying to design prerendered graphics in this way is that it'll eat up your memory extremely quickly. DKC on the SNES manages to look great because it has lots of frames of animation for everything, in very high quality color modes. It accomplishes this through use of a very impressive internal image compression scheme. See, the SNES has a very limited control over how its sprites work -- there is a flag in the object manager for the SNES called the Sprite Size Flag. the way this works is that it has 4 toggles that affect all sprites on screen at once. Either sprites can be made up of 8x8 tiles, 16x16 tiles, 32x32 tiles, or 64x64 tiles. Every sprite on screen, depending on the mode selected, must be the same size, even if the visual area is small. For example, if you're playing a game and want a big background sprite for a monster that would be perfect using 64x64 tiles, but shoots small dot-sized projectiles, if you use the 64x64 OAM size, your projectiles will still be 64x64 pixels big in memory, requiring 4096 pixels in ROM to define, like so:
That little 4x4 dot, say a projectile, requires 4096 pixels in ROM to define, wasting 4092 pixels in 64x64 mode. This is an enormous waste for a system that is already much less efficient at memory usage than it's competitors like the Sega Genesis. For example, games like Aladdin, Earthworm Jim, Sonic the Hedgehog, etc, use a form of image compression built into how the Genesis' sprites work to squeeze more animation into the system. Sega Genesis sprites can be independently sized, you see, not just in a square shape, but also rectangular. You can have one sprite on the screen that is 8x8 big, another that is 8x16 big, another that is 8x32 big, and the other way too, one that's 32x8 big, 16x8 big, and so forth. This allowed Sega to chop up bigger sprites into smaller sprites to save space, like so:
This is a few frames of animation for Super Sonic in Sonic 3. The green pixels are transparent pixels, but the black pixels are pixels that outright don't exist. In fact, these frames of animation aren't one sprite, they are 4 sprites, split vertically into horizontal strips. Look at the first frame of animation: the top sprite is 8x16 big, the second sprite is 16x32 big, the third sprite is 24x24 big, and the bottom sprite is 8x16 big. Instead of just constraining the sprite into a single 32x32 sprite, by chopping them up into smaller sprites, it winds up saving about 9 8x8 tiles worth of pixel data. When you draw sprites on the Genesis, it's common to begin each frame of animation with a vector table of offsets,telling each sprite how much to move to the right so that the sprite forms a complex shape. The SNES can't do things like this, the hardware literally does not allow it.
Third party games would use tools like Chopper to do this in games like Aladdin:
It's not merely enough to just use small sprites on the SNES and chop up bigger sprites, because when using 8x8 tiles on the SNES, there is a limit of only 34 sprite positions that can be held in memory, instead of the usual 128 that the SNES can use. So when using the smallest sprite size on the SNES for tiles, you literally have more restriction on how you can use them. This lack of ability to chop sprites to save space is why games like Earth Worm Jim on the SNES features way, way less animation than the Genesis version.
Rare began their life as Ultimate Play the Game, and before they made games, they were in demoscene. So Rare, more so than the average game company, already had lots of experience pushing really weak hardware in extremely efficient ways, and they do just this in DKC. They indeed chop up sprites into 8x8 tiles to save as much space on the cartridge as possible, to make it possible to cram as many frames of animation as possible, and they do this by getting around the 34 sprite limit by building a complex sprite multiplexer.
Sprite multiplexing is something that generally wasn't needed on SNES and Genesis games. It was an oldschool Commodore 64 trick, where the system only had 8 sprites to work with on the entire screen. Essentially, by using DMA down the screen while a scene draws, once all your sprites are used up on the screen, sprite multiplexing will change the sprite's location in memory so that they get redrawn later on the screen using the same hardware sprites.
True sprite multiplexing involves quite a bit of quick sorting, but the idea is to order all your draws for sprite objects from top to bottom such that the raster line will always be drawing new tiles as it reaches the end. This imposes a hard limit of 8 sprites per raster line (this is actually where future systems, like the NES and Sega Genesis and SNES and all that stuff gets their sprite per raster line limit from - those systems included sprite multiplexing in hardware).
Thus, your steps for sprite multiplexing are as follows:
1) Order all "virtual sprite" objects (a block of memory, not an actual physical sprite) from top to bottom according to Y position
2) map "virtual sprite" object to 34 (or 8 in the C64's case) physical sprites as they pass through horizontal band of raster line
This type of sprite multiplexing wasn't taught in magazines, it was picked up from demoscene, but a popular example of a game that uses it would be Ghouls n Ghosts. It's typical to see scenes that look like this:
Each bird and arthur are made up of two sprites, hence it is actually displaying 8 sprites for characters (3 birds X 2 = 6, plus 2 for arthur) plus 2 sprites for the guiotines, plus 1 sprite for the lance, meaning it's drawing 11 sprites at once.
Ordered, it draws them like so:
You can see the order reads from left to right, up to down. This is much more difficult than Zoning, because the "virtual" sprite can be made up of different physical sprites on any given frame. How quick you can sort and map the physical sprite objects determines how well your program runs. To demonstrate how sprite multiplexing is different from zoning, let's consider an example - say one of those birds didn't exist. The mapping would then go as follows:
See in one example, the arthur sprite on screen is made up of physical sprites 7 and 2 in one frame, and in the other example he is made up of physical sprites 5 and 8. Depending on the situation, and what is on screen, the physical sprites that make up the object can change on the fly. This is what sprite multiplexing does - it arranges the physical sprites between hblanks such that the process is invisible, both to the end user and to the programmer (they feed "virtual" sprites that they set up into a process they write to do the multiplexing). With Zoning, which physical sprites make up the "virtual" sprite never change.
Like I said, ultimately, this method became dominant and built into hardware, and virtually every 2D system afterwards used a similar multiplexing method. The number of draws hardware can do per raster line clues you in to how many physical sprites it can draw at once. Doing sprite multiplexing involved extremely deep integration into the engine, as objects must spawn in-order otherwise you'll waste cycles ordering your multiplexing list, and for a game like DKC which already does a lot, this is not possible. So their object handling system deep in DKC is remarkably complex, way more so than most other games of the era, because they do an intricate trick to push sprites that hadn't been common in about a decade by that point. DKC uses a similar compression scheme to genesis games like Aladdin, on slower, weaker, less suitable hardware, entirely through genius programming.
Then there are things like HDMA lists in the background:
Donkey Kong Country here is pushing an incredible amount of colors in this scene -- more than the SNES can supposedly produce at once in this graphics mode. It's due to it's use of HDMA Lists. The actual background for DKC looks more like this:
The far background, like the horizon line, aren't tiles or anything stored in ROM, it's actually a real time graphical effect being done as the game runs. The far background is actually one solid color, but as the screen draws, the SNES uses an HDMA list so that, every single time HBLank occurs on screen, it'll automatically poke and change a register in the SNES PPU hardware that controls the color of the background. By changing it a little bit every single horizontal line of the television, it creates the gradient background in real time as the game runs. This is similar to how Copper backgrounds on the Commodore Amiga worked, but on the Amiga, those backgrounds were created using a dedicated coprocessor (copper is literally a portmanteu nick name for "Co-processor"). The SNES here does it all in software, on the fly, without a dedicated co-processor. Again, this comes down to genius coding.
The DKC games are full of this kinds of stuff. There are areas where the programmers were only afforded 4 hardware layers to draw with due to how the SNES hardware works, yet they managed to simulate 5 or more layers using bitplanes. This is because of how the SNES stores it's graphics. Rather than using chunky image formats, where every byte in memory stores color information about a single pixel, the SNES uses planar memory. This means every byte in memory is actually a monochrome representation of 8 pixels in a horizontal row (1 bit per pixel, 1 byte = 8 bits in a row, so 8 "black or white" pixels in a row). Multiple bytes are interleaved in memory, and you represent this type of colorspace 3 dimensionally:
Very smart developers would realize that every layer of the bitplane produces a different monochromatic image when seen in memory like so:
It is when they are combined that you get the resultant final image. So, if you really understand how the video hardware works, you can cheat and use a single bitplane as an extra drawing layer, scrolling it independently of the other bitplanes in software. This limits the number of colors you can use -- a single bitplane only has access to two colors, "on and off." But again, coupled with HDMA lists, rare could change the colors being used to make that single bitplane layer in memory as the screen draws, so that instead of being monochromatic vertically, it's only monochromatic horizontally, with the image being a gradient vertically. If one affords two bitplanes to the trick, you can produce 3 different colors at once horizontally, allowing for complex images.
Here's a screenshot of such an affect from the Amiga game Agony showing the screen result and the vertical color palette being done by DMA:
Again, the Amiga had a dedicated coprocessor for this. The SNES does this in software. In the first level to DKC, Rare managed to make 4 drawing layers behave like 7 layers of independent parallax scrolling using this trick. And this is the complex type of parallax scrolling.
DKC is full of this kind of tech. Like, on top of chopping up sprites for ROM compression, they also have a few other RLE and LZ77 based compression schemes in the game. They use multiple, because certain points of the game need data quicker than others, and thus multiple compression schemes are needed to wring out every last drop of space on the cart. It does all this without any sort of co processor. In addition to this, there are also impressive line scroll scenes, palette swapping scenes midframe, the works.
DKC is hands down, without a doubt, one of the very most impressive SNES games. It's NOT "just pre rendered graphics," it's essentially a love letter to really deep gritty demoscene programming. The average developer, with an SGI workstation, could not have created DKC. You need to be extremely proficient at demoscene-style graphics programming to pull of a game like that.
And again, unlike lots of these games, NO CO-PROCESSOR. Keep in mind that the systems I'm comparing these types of effects to -- the Amiga, the Sega Genesis -- had an m68000 CPU inside, a far superior CPU to the SNES. In the case of the Amiga, it also had a dedicated co-processor to screen effects. These are tricks for machines with strong CPUs. The SNES's CPU, by comparison, is extremely weak, and thus to pull of these types of software effects quickly, on that CPU, while still running the rest of the game, is honestly amazing.
My hats off to 90's RARE, their games are pure, 100% technical wizardry. Absolutely masters of their generation.
I can't view the video at work, but does the video even bring up "pushing" the hardware? The title just says "the best graphics on the sfc." Or rather, a selection of some of them.
Last edited:
There is much more in the game itself. Last boss is made out of texture mapped(!) polygons.
The game is quasi a "best of GFX" of Super Turrican 2 and Super Probotector combined.
but again: I do think "Super Aleste" is a tiny bit more impressive. The sheer amount of super smooth scaling effects, transparecy (layers), parallax background etc etc at the same time is completly nuts to me. The game never slows down and , I swear. it's the only sfc/snes game which makes my snes(es) getting warm.
I remember checking a few uncompressed screenshots (gameplay) taken from emulators from some of the most colorful games on Mega Drive, SNES and Neo Geo and the max on SNES was around 200 colors at once which, by the way, was much higher than the average SNES games.
And you haven't seen yet the most impressive part of Rendering Ranger that is the asteroids storm (where the game engine pushed a lot of sprites on screens without slowing down):
http://youtu.be/8QNQvV0EUfc?t=1m4s
Last edited:
I don't think it's real time.There is much more in the game itself. Last boss is made out of texture mapped(!) polygons.
The game is quasi a "best of GFX" of Super Turrican 2 and Super Probotector combined.
I believe it's just 8 prerendered images.
Most SNES games average out around 90-150 colors displayed at most, depending on how many different elements are displayed on screen. There are some interesting quirks and limitations depending on which display mode is used. I've noticed in many games that UI elements are significantly sparse in color use. Like barely a step above NES. Is this due to the UI using a specific BG layer in one of the modes?
yes, UI elements typically are in the 2bpp layer.
They're not barely a step up from NES, they are the same limitation as the NES. Just with a bigger master palette to choose from.
There is actually a super interesting hack of Super Mario World that uses the very rarely used Mode 1, which affords 4 full background layers at 2bpp each. This produces parallax unlike what is normally seen on most consoles until things like the PSX shows up, but also looks like an NES game. The end result is that it confused many people in to thinking it was a modern "retro remake" game running on a PC:
Which of the games without any additional hardware in the cartridges pushes the limits of the snes the most ? I had Megadrive and my mother said i wasn't allowed a SNES at the time lol
I'd say the average colors on screen for SNES games to be closer to 90-110 colors.
The average colors on screen during gameplay is usually sensibly lower than the theoretical max.
For example Neo Geo is said that it can display 4096 colors at the same time but the max I've found was around 600 colors (King of Fighters 97, the stage with confetti) while the average was around 200 colors.
Cool.
I do not agree. The choppiness, the pixelation of the texture maps and the sheer simplicity of the boss are IMO a sign of realtime rendering.
just compare it to other real prerendered bosses in the game.
Prerendered:
(IMO) real time:
You're not wrong.
Man some of the creativity on display during the SNES/Megadrive days and the DS times.
Makes me sad that a lot of big publishers are playing it safe
