Crossplatform Titles Shortchanging PlayStation 2's Performance?

Thanks to GamerFeed for their new story noting that Sony Europe's research, using their 'performance analyzer', on the latest PS2 games. According to the piece: "The secret (or not so secret) way to unleash the PS2's power is to use its vector units (VUs)... of course, the games that used the VUs fared much better, and the game that scored highest did indeed use the VUs the most." An previous AnandTech analysis of the PS2's hardware explains a little further: "The power of the two VUs exists in the proper use of them as serial counterparts in handling the T&L calculations necessary during 3D rendering, but with the PS2 being... dramatically different from what most developers had seen in the past, getting the most out of the host CPU was quite difficult." The original article, in UK magazine PSM, concludes by pointing out: "A lot of the games that don't really use vector units are ports from other systems."

Comments

The problem is the compilers

[QuantumG]

Writing code for the Playstation 2's vector units is not exactly easy. There are no C compilers for the VU (Codeplay went out of business last year) so that means you have to sit down and write asm. Usually a game company will write some T&L code to go on the VU and then never touch it again, doing most the work on MIPS core. The VU can be used for a heck of a lot more than that. Unfortunately no-one can afford to do large amounts of programming on the VU because VU-asm programmers are hard to come by and the software they produce is impossible to maintain.

What would be perfect is a compiler that could take ordinary C code and turn it into MIPS+VU0+VU1 code automatically, taking the best advantage of all the machine's resources. Unfortunately this pretty much exists in the realm of science fiction.

Re:The problem is the compilers

[hibiki_r]

Assemblers are really, really low level, 1 asm instruction is typically equivalent to 1 machine code instruction, as opposed to the 3-25 of machine code the typical line of C code is like. Adding the extra complexity of specifying which registry each piece of data goes to and the lack of high level constructs makes assembly code inherently harder to maintain.

Also, there's the issue of the VUs being vector-based processors, which the typical asm-monkey or game programmer probably has little experience with. Add that to having 2 vector units available at the same time (parallel programming?), and ou get a machine that most 'mortal' game programmers don't get even close to being able to code for properly.

On the other hand, I've heard from people that had to work both on PCs and PS2s that they'd rather handle the PS2s assembler than having to suffer through writing video code that works properly on the myriad of video cards avaliable today, most of which have enough little quirks.Most changes in the 3d engine code have to be tested on at least 8 computers with 8 video cards just to make sure that the latest change hasn't just made any of the test setups crash due to some bing in the directx drivers for that card.

Re:The problem is the compilers

[bluGill]

Not sloppy code, but hard to maintain. ASM does not allow for a lot of nice things that structured langauges allow for. You end up with a lot of lines that move from one seemingly random memory location to a different one, change bits seemingly randomly, and place the result in a different location. It is very hard to see what is going on for all the irrelavant things that happen.

What makes it harder is nobody in their right mind would write in assembly unless performance is critical and no better algorythm is known, so assembly programers activly prefer hard to understand code that is fast over easier to understand code. That bit manipulation code above may silently depend on a side effect of an operation several instructions ago.

Read the story of Mel. While no assembly programer intentionally writes code that hard to understand without documentation, they all look for tricks like Mel would use because they should never be called unless the C compiler can't optimise good enough. No matter how much they document things (and correctly documenting your code is hard) it is by nature hard to understand.

Modern processors often have weird things going on too that you need to remeber. Delay slots, multipul pipelins to fill, and so on. A good programer (or more likely compiler) tune to take advantage of all this, but by nature is creates code that isn't liner.

Now the VU units can't be programed in C (appearently?), so they don't nessicarly have to use all the tricks in assembly to make it go fast. However even still by nature assembly is hard to understand.

mice

[Hythlodaeus]

Forget vector units... I'd like to see multiplatform FPS's make proper use of MICE on PC ports. "Enter the Matrix", "Deus Ex 2" - I'm talking to you.

VU Useage == Good Game

[MBCook]

It's the magic formula to success! No wonder the XBox is terrible, it has no VUs! OK, in all seriousness the VUs don't magicaly make games better, that is a result of the reason, not the cause.

This makes perfect sense. The developers who use the VU are the ones that take the time. Quick and dirty ports wouldn't use it, but if you take the time to optomize for the VU and such, then chances are you'll take the time to optomize other things. You'll make the sound work well, get rid of the logic glitches, adjust the diffuculty so people don't get stuck because you left out some clues to where the key is hidden, etc. The publishers and developers that take time to make great games spend some of that time one the VUs.

So, indirectly, it makes perfect sense that VUs make a good judge of quality. Now if only other publishers would stop making so much shovelware. The PS2 (and other consoles too, but especially the PS2) has a LOT of great games. But for every great game the PS2 has, it has TONS of shovelware. Unfortunatly, often the shovelware gets great marketing (Finding Nemo, The Matrix: Reloaded, BMX-XXX) and great games (Amplitude, Ico, etc) don't get nearly as much and so they don't do nearly as well, because a large number of games are bought by parents who don't know what games are worth money, or what aren't worth their weight in dust.

Re:Um?

[unclethursday]

Oh yes. I have Max Payne 2 for my Xbox (we got it for free from Rockstar, but have to review it for GAF as my 'payment'), and it is one good looking game, in most respects (character models could still use some work).

The PS2 version, by comparrison, is utter crap looking. Horrid, washed out textures, the overall blandness of the entire thing.

Still, the PC version, with the correct PC graphics specs (which I don't have), blows the Xbox version away in graphics as well, especially since PC version of the game can support much higher resolutions than the Xbox version.

I'm not saying games can't look awesome on the PS2, like it may sound like from my OP, really. Zone of the Enders the 2nd Runner is one gorgeous (and fluid moving) game, as is Final Fantasy X. But those are PS2 exclusive titles.

But, we all know that when most games get ported from the PS2 to other systems that they suffer from 'PS2 Port Syndrome'; where the developers do a quick and dirty port, without offering buyers on the GC or Xbox the graphical abilities these consoles have over the PS2.

UbiSoft showed that even with the limitations the PS2 has compared to the Xbox and GC, that you can still make a great looking game (Splinter Cell) and have it on all the consoles. In fact, IIRC, UbiSoft actually re-wrote all the rendering abilities for each console to be console specific, so that it would look good on all of them.

So, while Sony Europe may be right that games could look better on the PS2, blaming 'ports from other systems' is simply laughable (again, 9 out of 10 go to the others from the Ps2, not the other way around). Besdies, with a few exceptions, Sony published games don't look all that hot on the PS2, either.