🔒 Locked

Metal Gear Solid 1 PSX - Graphics Discussion

Started by jjanevski Jul 19, 2009 at 12:12 PM 30 replies 26.8k views

Original Post

Jul 19, 2009 at 12:12 PM

Recently I've been going through the original PSX Metal Gear Solid game. IMHO this is one of the greatest video games of all time, not only for its amazing story and game play, but also the great graphics relative to its time. I really appreciate the work and art skill that is put into make nice diffuse textures. Really has a sense of nostalgia. Anyways, I wanted to start up a thread to collect knowledge about the graphics, rendering tricks & techniques, and any info on the original MGS engine. If anyone knows anything about the game or any techniques it would be interesting to share it here. I noticed that the game uses a lot of textures repeated over the flooring in many places, as well as the wall. The artist did a good job to maximize the textures. This leads me to wonder how the level designs are stored. Did they use some sort of BSP engine since most of the game took place in corridor, or boxy/cube styled levels? Another trick that I was wondering about was the stealth camo. How did they pull off that effect with the stealth camo that Otacon used in the game. Was it just some env mapping and then they warped and modulated the texture a bit? Here are some screenshots of the MGS to refresh people's memory of what the game looked like.

pixelated textures... mmm mmm good! :) [Edited by - jjanevski on July 19, 2009 3:16:50 PM]

AndyFirth

Jul 19, 2009 at 2:57 PM

been a VERY long time since this game came out... probably a good idea to remind people with screens (me especially :D)

jjanevski

Jul 19, 2009 at 3:10 PM

That's probably a good idea. I'll edit the 1st post so I don't clutter up the thread with a huge image filled response. Thanks for the suggestion.

implicit

Jul 19, 2009 at 3:21 PM

Quote:
Original post by AndyFirth
been a VERY long time since this game came out... probably a good idea to remind people with screens (me especially :D)

Clicky.

They may well have used BSP-trees but I wouldn't expect to find much in the way of innovative techniques in there, rather making the game work on such underpowered-hardware was probably more a matter of hard work and careful design (along with plenty of shortcuts and approximations.) I don't doubt that the code is littered with bit-twiddling hacks and abuses of the graphics hardware, but at this level there just isn't very much room for complex algorithms and data-structures.

Still, I've always been impressed by how the PSX games managed to get by without Z-buffering.

edit: I'm pretty sure those Gamespot shots were taken from an emulator, considering the resolution and texture filtering.

jjanevski

Jul 19, 2009 at 3:35 PM

I think the first batch of screenshots that I posted were from the PC version.

I still am interested to know how they managed all the levels and culling things that weren't in view. Do you think it would have been possible that they used an octree and then just build the levels out of cubed shaped geometry? Everything in the game seems to be very square for the most part.

Krypt0n

Jul 20, 2009 at 6:30 PM

I think that's probably really BSP, one way to help in building an solid-BSP (especially for machines with no float support) is to keep faces coplanar to the "world planes", the bsp compilers used those faces first, arbitrary faces in the lowest leafs.

The reason i think it was an solid-bsp is cause this way you can completely avoid doing any triangle intersection stuff, and also, sorting tris into octrees is never optimal, either you duplicate tris, or you keep them on higher level so you've to test frequently against them.

the simplest way would really be to use bsp imo, using non-solid-hieararchies is good if you have high poly counts, but even then e.g. for raytracing, specialized bsps (e.g. kd-trees) are still the fastest for queries.

Promit

Jul 20, 2009 at 6:33 PM

For that matter, I can't find any documentation on the basic architecture of the PSX. What kind of constraints and craziness were they working with?

Edge Damodred

Jul 20, 2009 at 6:40 PM

A x2 CD Drive, 33 MHz MIPS R3000A processor, 2 MB System RAM, 1 MB Video RAM, 512KB Sound RAM, 128KB memory card(sectioned off into 15 individual blocks for data storage). And boy did they get some great games out of that! Reference.

dmatter

Jul 20, 2009 at 6:43 PM

Quote:
Original post by jjanevski
but also the great graphics relative to its time.

Clearly you've never played Spyro The Dragon, or one if its first two sequels, if you want to analyse impressive graphics for the PSX then that's the game to look at IMO.

Promit

Jul 20, 2009 at 6:46 PM

Yeah, I know how to read Wikipedia. I was looking for actual architecture. For example:

The 360 uses an in-order CPU with 3 hyperthreaded cores running at 3.2 GHz and a custom DirectX 9 class GPU by ATI with unified shader hardware. There's 512 MB of unified system memory (although it's unclear if this is DDR2 or GDDR3), along with a 10 MB block of high bandwidth EDRAM for the backbuffer, which provides essentially free MSAA. It uses predicated tiling for its rendering engine when stuff doesn't fit in that 10 MB. There's custom audio decode hardware in the CPU that assists decoding xWMA audio, and a ANA chip (HANA in HDMI models) that scales the game's output to the final target resolution. The graphics API is essentially DirectX 9.5, Shader 3.0 with extensions, and the operating system is a heavily modified Windows CE.

Notice the difference in detail level -- and ideally I'd like much more detail on the PSX. Come on people, it's not like those ten year old NDAs still matter.

dudeman21

Jul 20, 2009 at 7:02 PM

I haven't been through all of this stuff yet, but it seems there's random bits of information here and there spread throughout the 19 DVDs worth of material here. Expect lots of cut-scenes and marketing type "making of" stuff, but maybe there's something of use here:

http://www.freewebs.com/legacyofmgs/

Edge Damodred

Jul 20, 2009 at 7:06 PM

That's just it though, there wasn't much to the PSX. It was designed to be the cheapest 3D hardware they could make. It had a rasterizer and that's about the only help the hardware gave you, everything else you had to make. No API's, no hardware enabled anything. It was a hull, a mast and sail, everything else, including the rudder wheel had to be made by you.

Ravyne

Jul 20, 2009 at 7:21 PM

PSX homebrew docs ought to have more details, and leaks of the Yaroze docs are pretty informative as well -- these docs were the same as the full, official SDK docs, except the CD-ROM access docs/libs weren't included.

Geometry and clipping are done on the CPU with an integer vector instruction set -- I'd wager that the actual hardware behind it is 64-bits wide, and that it could handle 8x8, 4x16, and 2x32 integer operation (probably 64x1 as well) -- at least that's what the vector structs in the SDK indicated to me.

The rasterizer handles 2D and perspective-correct texturing in fixed funtion form (from the programmer's perspective anyhow,) IIRC it was actually a programable unit, but the firmware wasn't able to be changed by the developers, only by Sony themselves. Also, it was the last technical effort headed up by Kuturagi, who designed the rasterizer basically on his own.

Daaark

Jul 20, 2009 at 10:13 PM

Quote:
Original post by Ravyne
The rasterizer handles 2D and perspective-correct texturing

The N64 could perspective correct textures, but that was a feature PSX didn't have. That was one of the biggest problems with PSX games. If you didn't look at objects within a certain angle, the whole texture would warp at some point halfway down, like someone rotated the UVs by 45 degrees. Mostly only noticeable in free roaming 3D games.

That was a strange generation. The PSX could handle the highest resolution textures but only very low polygon counts. Then the N64 could do all the texture filtering, perspective correction, and higher polycounts, but most games had blurry 16x16 textures stretched over everything. The N64 had nicer audio hardware, but you had to use main memory to store the sounds, instead of dedicated memory like on the PSX. All the strengths of those machines had something that canceled them out.

I read somewhere a long time ago that PSX rendering was just a programmable list of things to draw. You set up your the list, and the machine just iterated over it and drew everything in order.

I've played a ton of PS1 games, and there was nothing I remember being technically impressive about Metal Gear Solid. It was a nice art style, and well presented, but it was just standard PSX level stuff.

Ravyne

Jul 21, 2009 at 1:28 AM

I could be wrong, but all the pictures I've found on the internet don't look like their UVs are swimming nearly so much that I'd assume there was no perspective correction -- a little swimming, sure, but that could be explained by low sub-pixel accuracy in the fixed-point rasterizer. Besides, if you go through all the trouble of designing the hardware, it takes just about zero effort to add perspective correction, and it wouldn't consume that many additional transistors either.

Daaark

Jul 21, 2009 at 2:00 AM

Quote:
Original post by Ravyne
I could be wrong, but all the pictures I've found on the internet don't look like their UVs are swimming nearly so much that I'd assume there was no perspective correction

I couldn't find any to post either. It's not an easy thing to find still photo evidence of, because that's not the time that people are going to be taking screenshots! You just have to see it in motion. It was a big issue back in the day, and on 1993 tech, which the PS was, it wasn't free.

When it happened on large polygons, it happen pretty bad. A 45 degree shift over one frame. They would pop in and out of looking correct.

It's hard to find good examples. a lot of the free roaming camera type games move so fast.

SaltyGoodness

Jul 21, 2009 at 11:57 AM

Quote:
Original post by Ravyne
I could be wrong, but all the pictures I've found on the internet don't look like their UVs are swimming nearly so much that I'd assume there was no perspective correction -- a little swimming, sure, but that could be explained by low sub-pixel accuracy in the fixed-point rasterizer. Besides, if you go through all the trouble of designing the hardware, it takes just about zero effort to add perspective correction, and it wouldn't consume that many additional transistors either.

Affine texture mapping artifacts were kept to a minimum by dynamically subdividing triangles according to their distance from the camera. This reduces the UV swimming, but in turn introduces triangle wave like artifacts. I only ever worked with the Yaroze devkit and I don't recall whether this was hardware assisted or not.

The PS1 was designed to be as cheap to manufacture as possible - it didn't even have a depth buffer! In those days the cost of perspective division would have been significant and when you're selling tens of millions of units, even the smallest of costs add up.

benryves

Jul 21, 2009 at 4:14 PM

Quote:
Original post by dmatter
Quote:
Original post by jjanevski
but also the great graphics relative to its time.
Clearly you've never played Spyro The Dragon, or one if its first two sequels, if you want to analyse impressive graphics for the PSX then that's the game to look at IMO.

">Quake 2 also looks pretty impressive, even if there is the odd seasickness-inducing texturing here and there. [wink]

implicit

Jul 21, 2009 at 4:54 PM

Quote:
Original post by benryves
">Quake 2 also looks pretty impressive, even if there is the odd seasickness-inducing texturing here and there. [wink]

Damn, that's an insane port. How the fuck did they manage convert a game designed for a high-end 16 MB Pentium to run on a 33 MHz fixed-point machine with a quarter of the RAM and no Z-buffering?
I mean the bloody thing still runs smoother than the software-rendered PC version and is better looking than the (bizarrely lit) GL version.

paradoxnj

Jul 21, 2009 at 5:02 PM

Promit, here are some specs I found.

http://www.consoledatabase.com/consoleinfo/sonyplaystation/index.html

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.