In fact, it had to be cut up into 16 chunks, and even then each chunk took 10 minutes to load! Our levels were so big, that our first test level, which never shipped and was creatively named “level1” or “the jungle,” couldn’t be loaded into Alias PowerAnimator even on a machine with 256megs. Dave meanwhile had to invent insane bidirectional 10x compressors to help get the 128meg levels down into 12, and figure out some tool for managing the construction of our gigantic 3D worlds. And the even crazier – way crazier – virtual memory system required to shoehorn the 8-16 meg levels the artists created into the Playstation’s little 2megs of RAM. I also concocted a crazy algorithmic texture packer that would deal with the fact that our gorgeous 512×240 mode left us with too little texture memory. Levels often took several hours to process on our 5-8 machine farm!
CRASH BANDICOOT 2 PART 1 CODE
By 1997 I had 4 gigs of ram in my machine! Of course some of those computational possibilities were so brutal that I had to code tools to distribute the calculations out to the video hardware, and chop it up onto all the office machines, where processing could be done in parallel 24 hours a day.
CRASH BANDICOOT 2 PART 1 64 BIT
And at the time, when a 50mhz Pentium with 8-32 megs of RAM was typical, our 250mhz 64 bit SGIs with 256 or 512 megs of RAM opened up totally different computational possibilities. This meant buying programmers $100,000 SGIs instead of $3,000 PCs. In fact the game itself even ran on the SGI (with terrible keyboard control). So we decided to use an entirely SGI and IRIX based tool pipeline. We conceived of using trees, cliffs, walls, and twists and turns in the environment to hide a lot of the landscape from view – but it would be there, just around the corner. As long as you could never SEE more than a set number of polygons (800 for Crfor Crash 2 or 3) from any given position we could have perfect occlusion and sort, with no runtime cost. Although painful and expensive, this worked really well. Dave and I experimented with pre-calculating the visibility and sort (the Playstation had no z-buffer, and hence no easy way to sort polygons) ahead of time on the SGI workstations the artists used.
The idea was that the camera would follow along next to, behind, or in front of the character, generally looking at him, moving on a “track” through the world. And Dave and I were convinced that extensive pre-calculation of visibility could allow the renderer to handle A LOT more polygons. So we did experiments in free roaming camera control and settled on branching rail camera + pre-calculation = gorgeous visuals. Dave, Jason, and I had done a bunch of research “post Doom” on visibility calculation. Mark’s was the best - being the best assembly programmer of us three - but also the most complicated.Ĭomplexity became the name of the game at Naughty Dog.
CRASH BANDICOOT 2 PART 1 CRACK
First me (three times), then Dave (twice), then finally Mark took a crack at it. No one else had the guts, as while this was easy to render, it required inventing some totally hardcore assembly language vertex compressors. This allowed us to use the more sophisticated 3-4 joint weighting available in PowerAnimator, which the Playstation had no hope of matching at runtime (until the PS2), instead we stored the location of every vertex, every frame at 30 frames a second. This gives a very stiff look, so we went instead with vertex animation. In those days, most people used a simple skeleton system with “1 joint” weighting, and very few bones. drum roll please… animation! We were obsessed with making ours look like that really good Disney or Looney Tunes stuff. The characters popped, like cartoons are supposed to, we had lots more polygons to work with, and it worked around the Playstation’s lack of texture correction or polygon clipping. This was a highly usual approach, but had lots of advantages. So we went with more polys on the characters, less texture. Jason pointed out - he’s always been the master of seeing the intersection between art and tech - that since polygons on 3D characters our size were just a few pixels, shaded characters actually looked better than textured ones.
In fact, just as fast in the 512 mode as 320. But it looked SHARP and we found the machine was really good at rendering shaded, but un-textured, triangles. The Playstation had this oddball 512×240 video mode that everyone else ignored, it wasn’t standard (320×240) and ate up video memory others wanted for textures. Our motto was “bite off more than we could chew, then figure out some crazy complicated way to make it work.” Since during fall of 1994 Jason was also the only artist, he frantically generated all the source material and banged on my head to make sure it would look incredible. While all this art design was going on, I, and then in January 1995, Dave, struggled to build an engine and tool pipeline that would make it possible to render these grandiose cartoon worlds we had envisioned on paper.
0 kommentar(er)
