In this thread we discuss clever techniques in games that squeezed every ounce of performance out of limited hardware. If there was ever a time you were playing a retro game and asked yourself "how did they do that?", post it and we'll figure it out.
Impressive graphical effects, sound, and implementation details all welcome. Bugs, although unintended, can be interesting to understand as well.
I'm sure someone remambers knows the details better than I do but the physics of your ship alone is amazing and IIRC this game goes around the NES sprite limit by soft coding every single object on the fly.
This. How the hell did they do Sonic 3's collapsing section at the end of Marble Garden with the VDP? There appears to be 3 layers; the background, the static foreground, and the falling sections. My understanding is that there are only 2 layers on the VDP. Is the falling section composed of sprites? If it is that is very impressive for circumventing the perscanline sprite limit flawlessly on so much terrain. Anyone know about this? And I am _not_ talking about the effect seconds before the boss fight when the level completely falls away.
Several effects in Toy Story for the SNES/Genesis. I know how the parallax floor was done, but not how they did the furniture. It looks like a 2.5D game.
Inevitable link to that blog post that explained how they compressed the levels and did the collision detection.
I've never played Sonic 3, but they probably erased background tiles one at a time and replaced them with identical-looking sprites.
And 5 background layers + a smoothly rotating sprite
And a 3D game engine with more features than Wolfenstein 3D's engine while running at 60fps and near native resolution.
I still find the tower levels in Mickey Mania very pleasant to look at, but I'm still unsure how they faked that rotation (the planks look great, shaded and everything).
Look for a sprite/tile sheet for the game. Chances are you'll see that they have perhaps 3 or 5 different angles for the background objects and they are layering them cleverly to give the illusion of 2.5D rendering. Pre-calculation was the secret sauce to the vast majority of "how did they do that?!" in the 80s/90s. Often you can replace all the expensive multiply/divide bits of the code with lookup tables generated on load. They are often very restrictive about how you can move around in a level so that the limitations of this approach aren't so apparent. For the wolfenstein section, I imagine that it's pure software by an ASM guru. It's only a very small chunk of the screen that's being drawn and well within the capabilities of even the SNES cpu.
>No one programs in ASM, silly, that's machine code
And what's wrong with programming in machine code?
>They write in C and translate it to computer bytes
>trusting C compilers producing anything close to optimized in the 90s
The 3D models on Evangelion 64 still amaze me, they look better than many 6th gen models I've seen.
that particular pic is from the model viewer, but even the in-game models look pretty amazing.
The PS2 smash clone game has shittier models.
It plays alright. If you've played the Ultraman games for SFC, it's basically like that but more realistic.
If you try to play it like a Mortal Kombat game, then yeah, I guess it "plays like shit".
And how about Game Boy Color.
For a while I just thought that it was an animated gif image, it'd certainly make a lot more plausible sense
Shit like this is why I wish there had been more European developed games for the Genesis/Mega-Drive, they could get so much out of that aged black box that nobody else could
I'm an amerifat, emphasis on fat.
This level's exclusive to the Genesis version. The landscape is a bit weird for a suburban road, but the smooth scaling is way better than, say, Space Harrier 2's.
Just my opinion, I guess.
Conker's Bad Fur Day
Pretty much everything Rare learned to optimize the N64 in one game.
Ridiculous number of simultaneous true dynamic lights by microcoding the RSP T&L engine to the metal.
Multiple directional scaleable shaped shadows.
Some basic pixel shader noise effects (used to make some directional light volumes appear more foggy/misty)
Real time MP3 audio decoding
The most impressive thing about this game to me is still Conker himself. I think it's his hands. Seeing fully rendered hands with individual finger movements in real-time was a little crazy. Most characters in every other game, including every other character in Conker's, all have those mitten hands that look like shit. But most of the time Conker's rocking individual fingers.
Even things like MGS and Splinter Cell the following generation cut corners there with conjoined fingers and almost every character's hands locked up like they're holding invisible guns. What else had cool hands?
The GBC is also really impressive.
I'm sort of surprised this hasn't been posted yet, but I guess it's because most people into "tech voodoo" probably already know of it.
Quake 3 Arena's fast inverse square root:
Sin & Punishment on N64 was fucking gorgeous. The ship section and astral plane section blew my mind, being used to N64's small draw distances and blurry textures. The cutscenes and all are remarkably high poly.
Nice to see Enduro get a shout-out, it's a very impressive game.
The math is a bit over my head, though.
>mfw playing in frameskip mode
actually I haven't been able to unlock it yet, but I've seen videos and it's fucking crazy
Space harrier looks cool, but the implementation is actually quite simple.
For a given perspective, the floor is composed of a background whose graphics are actually static and composed of many more than 2 colors, and the color palette is rotated every few frames. This gives the illusion of the ground moving. If you were to fill the floor's palette with random colors, you'd get a hot cosby sweater on the ground, not a checkerboard.
The sprites are mip-mapped so that they don't have to be scaled. This means that there are several copies of the enemy sprites at different distances. The distance the enemy is from the screen determines which size sprite to use to give the illusion of perspective.
The 3d nature of the game is just that, the game keeps track of a 3d playfield. You don't need a fancy computer to do 3d math; it's just 2d math with an extra coordinate. Yeah vectors!
This looks impressive, but there is no doubt in my mind that this is essentially an fmv movie reel. To prove my point, it would be impossible to change the perspective.
Still, an uncompressed movie on a GBC game would mean a shit ton of memory, which means some clever programming would probably have to be done to fit on a real cart and play at an interactive frame rate.
I'm sort of in two minds about the Crash series when it comes to technical merits.
On the one hand Naughty Dog DID used all of the tricks they could to make the game look as good as possible by not having a true real time rendering engine, but on the other hand other developers still tried to do everything in real time while coming up with tricks to make their games look almost as good.
For those of you who don't know what I'm talking about, Crash's engine boots performance by not calculating clipping, culling, visibility or depth, which are normally intensive 3D operations. The reason is that because Crash's levels are linear with a static camera that follows the same path every time and never deviates (except for the occasional branch) Naughty Dog pre-calculated 3D data on the disc for every frame as you move through each level. That's why it's one of the few PS1 that will freeze if you remove the disk - the engine literally cannot function without that pre-computed CD data.
it's a hybrid of realtime and FMV. You got the rasterizer working in real time, so you get all the benefits of models and textures (essentially really awesome compression, and interactive environments to some limited degree), while also getting benefits of FMVs (high quality visuals, because the hard math was done already). Sadly you also get all the disadvantages of models and textures (blocky look, since you're subjected to the limits of the rasterizer) and all the disadvantages of FMV (rails).
It's a good and worthwhile approach, in my opinion, that too few games used.
I know, I was comparing it unfavorable to the Toy Story level, which either scaled the sprites up via software or had a shitload of sprites for almost every possible distance (probably the latter due to the fluid animations in the rest of the game).
And more Toy Story. This level has a gigantic, albeit hideous Angela Anaconda-tier NPC walking around with smooth animation. It might be using vector art like Another World, I'm not sure. Nor do I know if it's using sprites or if it's a giant background.
The soundtrack is worth mentioning for its high-quality samples, although the guitar(?) is a bit shit. https://www.youtube.com/watch?v=XiDgEIPBFbk
It's pretty good. The story is pretty faithful to the movie. The gameplay changes every level, which keeps things exciting, but not everything works. The Pizza Planet stealth section is very repetitive: you saw everything that level had to offer in that webm. The RC car sections can be a pain in the ass due to the tank controls and constantly draining batteries. The camera is zoomed in a bit too close, and there's loading screens on the SNES version (though at least they were nice enough to tell you about the level while you wait).
Oh, and there's no save.
That's definitely a windowing effect coupled with HDMA.
The SNES had two windows whose intervals could be independently set and logically combined to clip either backgrounds or objects on a perscanline basis. It looks like they clipped all backgrounds and objects within the legs to reveal the null background color (the single color behind all backgrounds). The legs are animated by pointing to different HDMA data each frame of animation. Either this data is hardcoded (likely), or computed on the fly by drawing the window intervals using lines (less likely, but doable).
that could be applied every scanline to
Rails are not a disadvantage. Crash games are courses where you go from point A to point B. They felt like 3D versions of older platformer games.
Mario 64 introduced the idea of games as collect-a-thons that wore itself out FAST. The best Mario 64 levels were the bowser levels which were courses from point A to B. The whole game should have been those.
You forgot that the dudes shoes are smoothly scaled.
The game is full if insane tech effects like that, you also have a doom clone level, several racing ones, and the genesis version has an amiga tracker playing the title screen music.
>That's definitely a windowing effect coupled with HDMA.
I wouldn't be surprised if they were bigass sprites. The animation is too smooth on parts like the shoes. The 16-bit Toy Story games were known for having extremely big sprites and smooth animation reminiscent of the movie, they were also one of the biggest carts on either system (which also makes them a good choice if you want to build your socketed cart). So, they'd be certainly capable of moving that smooth graphics.
>can't tell you how many times I thought BFD looked like a PS2 game because of it
N64 has really strong T&L capabilities (Dreamcast is not even a full 3x stronger in that department), it's by far the best part of the console's technical features. So that's why really optimized games like Conker look like mini PS2 games (PS2 itself had T&L as its strongest point) in terms of polygon complexity and lighting.
>Rails are not a disadvantage
when you develop a game on rails you deal with the effects that the player can not, and must not, change the view in any meaningful way, which limits explorative gameplay and available stage size. Change of pace is occasionally possible, within limits. Sometimes not even that. It is virtually impossible to introduce any kind of backtracking mechanisms, as the view has a defined "forward" direction. All that makes it very difficult to do dynamic gameplay. For example an engine may or may not be able to remove objects from the stream. FMV rail shooters try to hide that problem with quick camera motions or long lasting explosions covering up the unharmed object.
Rails allow for massive detail, be it prerendered or precomputed, but there's a cost to it.
>The best Mario 64 levels were the bowser levels which were courses from point A to B
You're confusing A to B with rails. Linearity is not a problem, plenty game mechanics are linear, and for good reason. Rails are a specific subcategory, where there's very harsh limits on the linearity.
>Mario 64 introduced the idea of games as collect-a-thons
Crash looks pretty much like a collect-a-thon to me.
For the record: free roaming is not "an advantage" either, the very phrase you seem to imply that I said "being on rails is a disadvantage" is nonsensical. As you hinted, free roaming becomes hell for level design, because the player movement is much harder to predict. You get lower quality visuals, due to the overhead for a roaming 3D engines (even lower if you include streaming) and so on.
I'm frankly getting rather tired of people who are stuck in their black and white thinking, that take it whenever any negative aspects of a mechanism are pointed out, they turn it into a fucking duel of what's better or not. Learn some fucking nuance, learn the advantages and disadvantages of mechanics, learn that there is more beyond A good, B bad.
The animated intro to Sonic 3D on the Megadrive blew my mind back in the day. Although it looks pixellated as fuck I always wondered how they managed to do it with the MD hardware. I remember hearing that it took up 3/4 of the cart memory on its own.
C/C++ can't "get the full potential" of modern hardware either. It's simply a trade-off, control vs. complexity. That's why good engines, probably even back in the days, are tiered. There's a very good chance that a SNES RPG engine was coded in ASM, while tools were written by the devs for the authors, so they can do the state machine on a higher level, and it would be compiled.
This ran on old shitty PC's as well as it does these days. It had 3D environment and could display a fuck ton of sprite enemies at the same time, record their position, etc...
It's good programming. It was released in 1998.
>Although it looks pixellated as fuck I always wondered how they managed to do it with the MD hardware. I remember hearing that it took up 3/4 of the cart memory on its own.
I recall it used half the screen resolution magnified up. And it's just streaming in graphics, you can do that even on a C64, the only obstacle is the size it takes up on the cart/diskette.
>could display a fuck ton of sprite enemies at the same time
Sprite limits are a part of sprite based rendering hardware. PC/DOS just does pixels, and you can draw how many sprites you want, but you have to do it in software.
Pic's 3 years older, runs at the same resolution, and has a ton of sprites on this very screen.
Not a good example. RPG engines are traditionally outdated. In 1998 Quake 2 was already a year old. That was accelerated full motion 3D rendering with colored light sources and much more.
Some Genesis games were written in C (notably Ecco the Dolphin). The 68000 CPU is much better suited to C than the 5A22. But even so, Ecco didn't have a lot of sprites on screen most of the time, and in the rare cases it did it had slowdown.
Another page you folks may like is;
Yes, it is tvtropes, and it contains non-retro games, but it still has many great retro examples, like: https://www.youtube.com/watch?v=wFwbfN18x0I
terrible example, due to the restored audio. Get your hands on the original, because that's all you hear when you boot up the game. Also, that intro seriously FUCKED the style of the game. It clashes badly, destroys the original intro. It was a waste of cart space
There's a lot of mountstupid.png on there, but Exile's entry is correct. It feels like a modern indie game instead of an 80s home computer title.
Pioneer Plague, one of two games on the platform that used HAM mode for 4096 colors. Though the answer to "how did they do that?" is probably "by sucking".
Shoutout to the soundtrack for sounding like a bunch of deaf kids had broken into Prince's studio. https://www.youtube.com/watch?v=PWFhvJ8yWyE
The Bowser levels are where Mario's abilities like flying and wall jumping could have been really fun/rewarding. Just collecting the red coins in those levels was league more satisfying than jumping into whomp's for the 8th time
PS1 (PSX) Specifications : CPU - 32-bit MIPS (33mhz) GPU - 32-bit R800A (33mhz) System RAM - 2mb Video RAM - 1mb
PC Minimum Requirements : CPU: Pentium® 90 MHz processor or higher or Athlon® processor 16MB RAM required for Windows 95/98, 24MB required for all other supported operating systems
Even when considering the normal power gap between PC/console, this is insane that it ran so well. Quake II was a benchmarking title for a number of years on the PC until Unreal Tournament/Quake 3 came out. The original Unreal was a lot tougher, and more graphically impressive, but it never caught on with benchmarkers. Unreal was originally going to be ported to the N64, but as the game neared release it was obvious that no 5th gen console could even come close. It probably could have received a PS2/Dreamcast port, but in some ways it could be more demanding than UT99.
It looks like it's a lower framerate because it was taken from a youtube video.
The Genesis version really does have a lower framerate, but it's larger and has additonal effects.
What taxes performance of a raycasting engine isn't drawing sprites, but the number of rays it casts. Wolfenstein 3D, Doom and uh, Noah's Ark 3D look blurry as shit on the SNES.
>He never played the Playstation version with The gimicky 3d levels
Compare both versions to Jurassic Park on the SNES. You'll notice that it lacks the fog and floor texturing, and runs at a lower resolution and framerate. And the 3D sections are half the game, versus a single small level in Toy Story.
>Unreal was originally going to be ported to the N64, but as the game neared release it was obvious that no 5th gen console could even come close.
There are plenty of N64 games that look better than Unreal. The Legend of Zeldas, the Turoks, Banjo Kazooie, etc
toy story lacks actual gameplay, you can only interact with walls and doors
it's just a tech demo that freed up a lot of cpu power by barely doing anything outside of graphics rendering
There's no restriction on draw distance in Unreal and the texture detail is incredible. The only thing in Turok even comparable are the animations in Turok 2. And they nearly kill the N64.
>This looks impressive, but there is no doubt in my mind that this is essentially an fmv movie reel. To prove my point, it would be impossible to change the perspective.
Yeah, if you want a more high-res example of this try the Hot Wheels Stunt Track Driver game on the PC. That game is fully FMV based.
wow, I didn't even realize, good eyes, and well played by the devs. Because they still need to use tiles as output, and because the SNES can natively flip tiles, that mirrored output comes "for free"
Good point with with the mirror images, but it still has some semblance of floor and ceiling texturing whereas Jurassic Park does not.
Not to shit on Jurassic Park though, those 3D sections were awesome. Too bad it was a long-ass game with no saves.
I've always wondered how on earth they made the peeping hole from Kafei's hideout look into the Curiousity Shop in MM.
There's no transition or loading screen. I assume there's a copy of the shop that's connected to the basement of the Laundry Mat.
>HOW did they get Quake II to run better than Doom on the PS1?
Because the detail in the levels is severely cut down. They added walls to prevent you from seeing too much. Oh and the lighting is not truly RGB like it is on PC.
The N64 version could have been the best if only the animations weren't so horrible. It's got the full RGB lighting and the detail isn't badly cut down.
The original soundtrack wouldn't have hurt either.
I mean relatively speaking for people without a 3D accelerator card.
The PS1 version of Quake 2 is better than the N64 version because the PS1 version is nice and polished while the N64 version is really inconsistent, with nice features here and there but really nasty downgrades elsewhere.
even without an accelerator the Windows version has resolution on its side. It also has perspective correct texturing, which is a bit of a difficult thing for the PS, and handles considerably larger areas than the PS version. The PS version looks more like a proof of concept for a tunnel fps
I'd post some impressive-ish Spectrum games, but already I know how they did everything.
>"A 1-bit clicker with only on and off states. Basically through bloody software."
I only have an emulator, but I'm pretty sure it is. The Spectrum was the cheapest color computer you could get in 1982 and that game was based off the top-of-the-line Star Wars arcade game.
Fat Worm Blows A Sparky runs quite a bit better.
One thing that always impressed me was the boss of the third shmup stage in Turrican 2 on the C64 which had 3-4 background layers scrolling in every direction at high speed.
I can't think of any other game on that machine that did that.
You know what?
The C64 Turrican games as a whole are a case of "how did they do that?".
Quake 2 is polygons. PS1 can handle polygons. Doom for PC is a column based 2.5d renderer, not PS1's cup of tea. It was optimised for 386 with VGA, using Mode Y to make use of the faster VGA memory. Porting Doom PC code the PS1 means getting rid of most of the renderer completely or adapt it to make it work but with hindered performance because it doesn't use the available hardware optimally.
should be trivial to ignore the whole raycaster thing and just render floor and walls using polygons, no? Probably causes problems though with viewing distance, perspective correction, etc.
You do make a good point though about a raycaster requiring some ugly workarounds to render on a sprite and polygons focused system
This blog is full of self-praising bullshit and lies.
Like how Naughty Dog were the ONLY video game company that used SGI workstations.
Uh...every developer that wanted titles out for the N64 in the first year had to use them because there was no dev kit yet.
there's no speed limit on scrolling. When coding it's a simple matter of setting the offset for the window position, and possibly updating some tiles. That's well within the means of the SNES
I don't know if you took a look at other 3D games at the time. I don't care about how technical it is, but for starters, just look at that complex level geometry. In a time of bigass polygons and 45 degree angles, Crash Bandicoot's fine organic shapes make it look years ahead of its time.
>And how the fuck did he not release it? How do you fuck that up?
It was ridiculously difficult to get a publisher during the GBC days. Many projects, including the legendary Tyrannosaurus Tex, and almost Shantae, never got released, because publishers were too chicken. Shantae got published by Capcom after Wayforward has been searching for well over a year, the game already finished. Even then, Capcom only did a minimal 14000 units run, afraid of it failing. It ended up becoming fairly rare because of that. For emphasis: Wayforward was an established developer at that time, the game was done, ready to ship at any moment, and yet they had difficulties finding a publisher willing to publish a finished and good looking game.
big textured polygons actually require a fair amount of processing power to get looking right
for starters you need perspective correction because without it the texture on that big polygon is going to look glitchy as fuck
I'm not yet at that point. All the crash worshippers just make me want to never ever try the game, so I have no clue if it's good, or bad, or what it's like. Probably better that way.
in my experience the "hate" is a reaction to extreme praise, either because that praise is just plain annoying, or because people playing it because of the praise are thoroughly disappointed and consider it a waste of their time. And on top of that disappointment, they have to deal with the praisers calling them names for not "getting" the game
Any thoughts how did they do that?
I can explain rotating car, violet floor, and even T-Rex (well hidden bunch of sprites), but I can't explain the wall on the right.
1 year can make a BIG difference in PC gaming. In 1997, Quake II had a 256 color software renderer with monochrome lighting and no texture filtering. 1 year later, Unreal was released, which also had a software renderer, but with 32-bit color, colored lighting, fog, light coronas and unique texture filtering comparble to bilinear.
Red Zone CGI intro and gameplay
Quake IIs software render is a work of art. Check out the process here: http://fabiensanglard.net/quake2/quake2_software_renderer.php
Carmack had intended Q2 to use higher colour in the software renderer by way of MMX but they had problems with the bandwidth.
I actually have that game now and I'm impressed. Many Ps1 ports of classic PC games (both MS-DOS and Windows) had terrible framerates. The levels have been cut down. The graphics look better than it would on my old 1999 laptop (320x240 software rendering) and the gameplay is smooth.
I'm playing PSX Q2 too atm and it's damn fine a console FPS. It has its limitations -- more likely RAM than rendering. The framerate consistency is so good that the reduced geometry must be a matter of RAM rather than speed.
I played crash 1 and 2 a lot as a kid so this is a biased post, but I feel like the only reason it gets hate is because the people who hate it either aren't platformer fans in general or are just trying to be contrarian faggots. There is nothing wrong with not liking the game, but there are no parts of it that stand out as inherently bad (no major glitches, bugs etc that break the game. No absolute bullshit hard areas or incredibly easy ones)
I'd say it is worth trying the series if you enjoy platformers, but note that it isn't really about your skill with button presses and fine control to get you around the level like in Mario 64, most of the difficulty comes from timing your jumps and attacks and reacting to things quickly.
The first game is more barebones in features, but is incredibly harder to complete 100%, while the second game is less tough as balls in some areas, but has secrets all over the place and dank level design.
If you are looking for some platformers to try in general I'd recommend Croc, Tomba (Tombi in Europe), Super Mario Land 1 and 2 on GBC and
Super Paper Mario on Wii
Because this is what most 3D games looked like at the time.
Actually, i remember reading somewhere that the game was going to be stage based instead of objective based, but i think that was scrapped due to memory limitations so the game turned into having to go to the same stage 6 times instead of having a lot of complex linear stages like the bowser ones.
I think at one point it was going to be like yoshi island where you got some objects to collect (likely red coins) but you could just play the level normally and move on to another.
From what I've read myself the game was planned to be fixed path with an isometric viewpoint, yet this was very, VERY early on in development. It wasn't due to memory limitations that the current approach was taken but more that the team changed their minds.
The multiplayer, however, was the feature that was cut out due to memory limitations; that said, SM64 2 was supposed to have added it back.
I never actually played it, but wasn't the N64 version of Resident Evil 2 some kind of masterpiece of compression technology at the time?
That they kept most of the audio and fmv files from two PSX disks and fit it all onto a single N64 cartridge is far beyond my understanding, I also understand that all the in game textures had double the resolution in it too, compared to the PSX original.
>dat PAL cover art
>It looks like it is, why wouldn't it be? It's certainly not resource taxing assigning goraud shaded lighting to a vertex.
It actually is technically colored lighting, but it is not fully dynamic like the other versions. The levels seem to be divided up into fixed colored light emitters with the distance from the emitter determining the luminosity.
The amount of lighting used in the level design in this version is also less. Rooms just have a few lights each instead of a complex arrangement. I think the use of the lens flare is designed to cover this up.
Despite how it looks, the Space Harrier port on the ZX Spectrum is amazing. Compare it to the other "3D" arcade ports it got:
Alien Soldier always seems to blow my mind with it's impressive movement of enemies.
How the hell did they pull off graphics like this in 1983?
How the hell did they pull off graphics like this in 1983?
Crash broke new ground visually, but gameplay-wise it could not be more ordinary. It took the most sensible and safe possible approach to making "Mario in 3D". There's no difficulty spikes, aimless open worlds or obtuse mechanics. The platforming is more forgiving than Mario and Sonic. Like Nathan Drake, Crash is a character archetype that has been around for decades.
Both the Uncharted and Crash games are 10/10 if you consider goodness to be the absence of badness. I don't.
I'd say they're roughly equivalent.
The gba and snes have roughly the same amount of vram, but the gba only has about half as much ram for the cpu.
One other difference is the fact that they both have different architectures.
The gba uses ARM while the snes uses 6581.
ARM processors use a reduced instruction set, so they require more cycles to complete a task compared to a full instruction set like the 6581 or 86x architectures. The advantage if a reduced instruction set is being highly efficient, thus allowing the cpu to run at a higher clock rate.
Between a higher speed, but less things done per cycle, the gba pulls out slightly ahead.
One other difference it that the gba cannot accept expansion chips like the snes can, but I would say that the gba's raw processing power is probably equivalent to the SFX chip.
You don't need to sort the polygons. With the camera only facing one direction, their Z coordinate (or what ever points into the screen) determines the order automatically. Figuring the order of polygons is an expensive problem.
With the camera not moving you can make assumptions for culling. For example if you draw boxes, you can automatically cull the face opposite the camera, the face on the bottom of the box, and the face that's facing away from the centerline. If you're extra cool, you won't even include these in the model. They'll never be visible, due to the fixed camera angle.
The GBA is considerably more powerful than even the SFX chip. On top of that, it has additional capabilities regarding video output, like one of the video modes providing a continuous memory model of palette indexed pixels, which is extremely helpful when doing custom engines, instead of tiles + backgrounds.
>I imagine Super MArio FX would've looked a bit like this.
>still believing that myth
I used to be impressed by the presence of voice clips in NES games and anything before it.
What still impresses me now is that opening scene from Star Ocean on the SNES
Speaking of voices in SNES games, Tales of Phantasia is a great example of this. Not only does it have a voiced prologue, but a full-fledged song with vocals as well.
Two other games with spoken words are Super Metroid (the opening) and EarthBound. (the "I miss you" at the end) But they don't hold a candle to what Tales of Phantasia or Star Ocean pulled off.
I used Webm for Retards and set the bitrate to the maximum possible. The framerate is low, the colors don't change that much and the pixels are chunky.
snes can't rotate or scale sprites, only a tile layer.
the rotation effect on question is probably a bunch of pre rendered tiles, possibly using both hardware flipping and a quick 90 degree software rotator to cut needed tiles to a quarter
Pixar wouldn't have known anything about how to squeeze performance out of a game console. However, they did donate the 3D models you see in the game. http://gamesdbase.com/Media/SYSTEM/Nintendo_SNES//Manual/formated/Disney-s_Toy_Story_-_1995_-_Buena_Vista_Interactive.pdf