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

[Robmonster]

VU-asm programmers are hard to come by and the software they produce is impossible to maintain

Why is the code they produce so hard to maintain? Is there something particular about the languege used that leads to sloppy code?

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.

Focus more on the software than the platform

[trajano]

A lot of games or programs on any platform including the PC do not take full advantage of the platform. The best way to take advantage of the platform is to code in assembly.

However, this is not really the best use of time for people. Developing in higher programming language in a cross-platform way will end up with better SDKs for the game company.

Here's the priority list I would run my game company.

Focus more on developing good games first. The principal task of a game publisher should be to get his game sold not necessarilly selling the console.

Make it easy for your developers. Choose the platform where it is easiest to program your game in so you can get to market quicker. If your game is good enough, people will buy the console to play your game.

Expand your audience. You can port your games to other platforms at this point. This exercise will promote code abstraction and re-use within your development group.

This is where you start grouping your programmers into the "just-do-it" crowd and "do-it-properly" crowd. They both have their uses.

The "just-do-it" crowd will make you reach your market first. Don't put too much of into this effort. Its going to be too frustrating and boring for most of them, shove them into new development ideas.

The "do-it-properly" crowd will tend to make things slower, but should know how to group and make things better for the code base. They should be promoting code re-use and proper abstractions to help porting to other platforms easier. Don't put too much of them into new development otherwise you'll have conflict with the "just-do-it" crowd.

Learn from your successes. Focus on this one first, as its more positive to your employees. Expand your libraries. Promote code re-use. Think of the sequel.

Learn from your mistakes. Prevent problems in future projects by learning from them and removing the people that don't.

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.

Re:Relative power of machines

[Naffer]

Yea, have a look at Gran Turismo 4, and then scrub the jaggies out of your eyes with a rough sponge. Yes, the game looks better then previous PS2 games. I own a PS2, and will be buying GT4, but it really isn't all that incredible. It's not just the 300Mhz RISC processor that slows down the PS2, but the lack of RAM as well. Sure there are great methods for swaping textures using the PS2s quick bus speeds, but why bother? Sure, some developers will always spend the time to dig through the spec sheets and program for the extra VUs, but at what cost?

Consider this: How much quicker and more complete could a game be released if the developers didn't have to spend countless hours coding ASM for sony's extra units. What if they had enough RAM for a full scene, and didn't need to do creative swaping? What if all the energy poured into making a game run decent on the PS2 could be put into the game itself. Sure, there are techniques to be used that make the PS2 a formidable system, but techniques take time, and time as they say, is money. I for one, hope Sony does a U-turn and sticks with a single chip or CPU+VPU setup next time.