[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/vr/ - Retro Games

View post   
File: 153 KB, 800x600, ff7.jpg [View same] [iqdb] [saucenao] [google]
2331828 No.2331828 [Reply] [Original]

Hey, /vr/. After reading the blog about how crash bandicoot came to be on the playStation, particularly the technical challenges with the ps1, I'm now interested if there are other articles like it. I heard there's a bunch of stuff on the GDC vault, but unfortunately most of it isn't free. So I was wondering if there are other text based stuff like this which details the postmortems of facing both technical and game design challenges for some famous games. Final Fantasy 7 would be a nice thing to read about if it's available. Or is the Ultmania the only source?

>> No.2331848

>>2331828
The Crash Bandicoot post-mortem/timeline is detailed and really cool when explaining how many corners were cut to push the game's visuals with fixed camera views and shit: http://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1/

Shmuplation's is rich with interviews, some of which are more about development/technical issues than others (the Ys articles, for example): http://shmuplations.com/

>> No.2331849

>>2331848
I already read the first link, but the second link is a good start.

>> No.2331854

>>2331849
General FF7 interview (mix of technical/creative questions): http://shmuplations.com/ff7/

There's more arcade-related interviews there for the moment, but the Symphony of the Night one looks meaty.

>> No.2332024

>Narita: Yeah, in a certain sense, FF7 is something of a minor miracle. I mean, we only had a year to do everything.

What in the fuck? I don't believe FF7 took a year to make.

>> No.2332114

>>2332024
It's hard to say what he was referring to, as that line is taken out of context -- that article is cobbled together from several different interviews. I think he might be talking about assembling the final game, incorporating the backgrounds and maps, programming the battle system, etc. The assets were created first.

>> No.2332128

>>2331848
Crash Bandicoot's development can be easily summed up to this: they realized that with a fixed camera they could pre-compute geometry visibility from all possible cameras positions and store it on the CD, saving the PSX the effort of doing it manually, and more processing power could therefore be geared into pure churning out of polygons.

>> No.2332136

>>2332128

I find that insane to think about. How can you precompute every single camera angle?

>> No.2332139

>>2332136
The camera is on rails. When you walk through a level the camera follows the same path every single time. They pre-calculated geometry visibly for every step that Crash takes the camera forwards or backwards (Crash himself and enemies are not included in that calculation, only the scenery). The user has no direct control to move the camera left or right, so the matrix of data is basically 2D.

It is insane, that's why the CD drive was getting hit so hard. That's why they maxed out usage of RAM to buffer all that precomputed data.

Of course, you can only do this kind of thing for a Crash style game. Need a completely new game engine for anything free roaming, like Crash Team Racing.

>> No.2332148

>>2332139

I can understand the concept, it's just the sheer magnitude of data that baffles me. How does it fit in RAM? Is it streamed from the disc?
I don't know how the PS1 can process every camera angle on the rail. Even in a 2D data structure that's a huge amount of information,

>> No.2332157

>>2332148
It streams from the disc, but data slightly ahead of time as well to act as a buffer (in case the CD doesn't load it by the time Crash gets there). If you run through a level really fast in Crash 3, sometimes the game will freeze for a second to catch up.

It's a lot of data, but ultimately it's just massive sets of integers, nothing more than that. The magic is the PSX doesn't have to do anything other than make sure the geometry that is occluded is not on a display list.

>> No.2332212

>>2332157

As someone who doesn't know much about 3D rendering, can you explain what exactly is contained in these precomputed display lists?

>> No.2332217

>>2332212
Coordinates of the wireframes for the polygons to be mapped onto.

>> No.2332848

Jimmy Maher's summary of Elite's history focuses a lot on how technical constraints designed the game for Bell/Braben: http://www.filfre.net/2013/12/elite/

>> No.2333027

>>2332024
no but they did switch platforms at the last minute. probably what he's referring to

>> No.2333471

>>2332157
>>2332217
I think there's been some misunderstanding here. In crash, the 3d transformations on the vertices for the scenery meshes aren't precomputed, they're done at runtime. The precomputation is for the polygon sorting and occlusion culling.

This is much more accurate:
>>2332128

>>2332148
> How does it fit in RAM? Is it streamed from the disc?
The game utilizes a rather complicated virtual memory system where 64K pages are "paged in" from the disc as needed. The .NSF files on the game disc are quite literally pagefiles, one for each level.

>> No.2333482

>>2333027
No they did not. Where are you getting this information? FF7 was always developed for Playstation.

>> No.2335103

>>2332212
When translating a scene into a rendered image, determining occlusion (i.e., stuff blocking other stuff from visibility) is computationally expensive. By building z-indexes beforehand you free the processor up to do other things; just (precaching from the CD and) reading them out of RAM is much faster than building them at runtime.