Hacker News Reader

Comment by Nition | Hacker News Reader

For Crash Bandicoot (1996), Naughty Dog sidestepped the entire VSD performance problem. Since the camera is on rails and only moves forward and back, they pre-calculated the visibility for every position and stored it in the game's data. That meant no visibility calculation needed in real time at all, and they could do it per-pixel. As a result of that and some other brilliant tricks, they were able achieve probably the best graphics on Playstation.

View on HN

That's a very cool example of doing the "inelegant" thing and it just being objectively better. Am always on the lookout for these anecdotes, thanks!

In the same game, for character animations, instead of just using bones like others were doing - often resulting in some big distortions with low-poly characters - they set up per-vertex animation, letting the artists manually position any vertex every frame. Then wrote a custom compression algorithm in assembly to store it.

Not to mention actively streaming levels from the disk while you were playing them.

The whole thing is a great story.

https://all-things-andy-gavin.com/2011/02/02/making-crash-ba...

Yes! And the best part of that feature:

> Andy had given Kelly a rough idea of how we were getting so much detail through the system: spooling. Kelly asked Andy if he understood correctly that any move forward or backward in a level entailed loading in new data, a CD “hit.” Andy proudly stated that indeed it did. Kelly asked how many of these CD hits Andy thought a gamer that finished Crash would have. Andy did some thinking and off the top of his head said “Roughly 120,000.” Kelly became very silent for a moment and then quietly mumbled “the PlayStation CD drive is ‘rated’ for 70,000.”

> Kelly thought some more and said “let’s not mention that to anyone” and went back to get Sony on board with Crash.

I don't understand what that means. 70k per what? 120k per what? What is a "hit"? A read operation?

I would interpret it as completing the game requires 120,000 disk read operations, but the CD drive may fail after just 70,000 read operations.

70k per lifetime of the CD drive. 120k per complete playthrough of the game. A hit is reading from the CD.

Looking at the data sheet for a contemporary Sony CD-ROM mechanism

◆ Service life of feed motor

The current consumption of feed motor must be less than initial value plus 30% after 50,000 cycles. (1cycle : innermost track → outermost track → innermost track)

◆ Service life of limit switch

The contact resistance must be less than 100mΩ after 50,000 cycles. (1cycle : innermost track → outermost track → innermost track)

◆ Pick-up slide operation

The pick-up should operate perfectly after 50,000 cycles. (1cycle : innermost track → outermost track → innermost track)

Why did it work, though? Wouldn't the disks die halfway through the game? Did they end up cutting / optimizing the feature?

The rating was the minimum number of reads the motors in the CD drive of the Playstation would work for. Most likely, the rating was really low compared to what the drives could actually do.

It might not have hah. Early version Playstation 1 consoles had notoriously bad CD drives that failed all the time. It had something to do with poor quality plastic gearing on the laser carrier or something.

Would certainly be interesting to compare Crash Bandicoot playtime on failed vs. working units.

Limit is not on "reads", but seeks - its about sled wear. Sony infamously used plastic laser sled skid in first revisions.

https://github.com/JonathanDotCel/psx_clean_laser_mirror

https://psxplanetcodes.tripod.com/repair.htm

Plastic, unlike brass, wears out quickly due to friction. Quickest test was flipping PSX upside down, worn out sled unit would start playing perfectly again in this orientation.

so Yes, there was a rather low seek (move up and down) limit on first units caused by cheap design and inferior manufacturing process.

An anecdote: I regularly played Crash Bandicoot with my family while young on a PlayStation, and our device always had disc drive issues. Pretty sure we even went through two PlayStations while playing that game lol. Still loved it!

Quake 1 and 2 did this as well. I wasted so much time with details that later got botched by the vertex compression. I think Quake 3 had vertex animation too, but they split the character at the hips so it could face away from the direction of travel.

The hip swivel worked well, functionally, but I always lamented how stiff the character animation looked because of it.

Was the vertex compression responsible for the wobbling/swimming effect you'd see on models, when running Q1 and Q2 in OpenGL mode?

Yes

There must have been some cleverness in representing this data in a compact way, esp as it would have competed with the 150 kB/sec CD-ROM bandwidth streaming other asset data?

Weirdly the excellent devblog that I got all this info from[1] mentions crazy compression algorithms for the vertex animation and for the level files, but not specifically for the occlusion data.

[1] https://all-things-andy-gavin.com/2011/02/02/making-crash-ba... Especially part 3.

I think occlusion was just per vertex.

Jason Rubin says this on the blog:

> Our occlusion worked on a texture level. That is, if we had a giant polygon with a fern texture on it (think many leaves but lots of empty space) the occlusion could actually get rid of polygons behind the leaf part of the texture but leave the polygons seen through the alpha channel holes. No other game had that kind of detail in occlusion, and it paid off immensely. Given how small ground polygons could be in the distance, a little fern action went a long way.

There's a video series on YouTube where game devs talk about the challenges they faced while driving the game. Crash Bandicoot is covered in one episode, and there is another fantastic episode about Dead Space with the tentacle scene. Much recommended view.

There's quite a few videos.... Can you link to the specific one your thinking of? Cheers.

I'd guess that they are referring to this video by Ars Technica https://youtu.be/izxXGuVL21o

Reply on news.ycombinator.com