Late: Situations where PS2 outperforms Xbox

Exactly Phil, I'm in total agreement here. The myriad of ways a developer can extract performance from a said architecture is largely dependent on the devs. proficiency, creativity, art assets, time, budget, etc. Their opinions are formulated by their chosen method that gave the programmers their desired, or produced the most ideal results for what they were attempting to acheive. It is simply a variable/s, no two studios will have an exactly identical way of addressing or optimizing code, attempting to circumvent a bottleneck, the most efficient way of utilizing all available resources & architectural assets, etc.

There is no one developer's numbers claim to swear by, or programming methods for that matter. This is no disrespect intended towards ERP, (as I definitely respect him & his technical expertise) could he have created RSIII, MGS3, RE4, Halo, MP, GOW, etc.? Conversely, does that make any of his preferred programming methods any less viable on the projects he has worked on? He is obviously under NDA, but his programming opinion is by no means an industry standard. (as I'm sure he would agree) While certainly the hw will present technical hurdles that simply cannot be overcome, performance extractions vary greatly across the board for the aforementioned reasons.
 
Last edited by a moderator:
Sis said:
Should I invert my statement? I mean, what the hell was my post but exactly what you just asked for, but then chastised me about?

Particle effects are better suited on the PS2--from what I've heard.

For an example, please see Burnout 3.

What's your problem?

.Sis

You misunderstood what he was trying to say. This kind of threads tend to degenerate quickly into "X console is more powerful than Y console" flamewars. He doesn't want that. No one wants that, apart from the kids.

Anyway, in conclusion, yes PS2 is better at particles, so games relying heavily on particles will tend to run better on PS2.

I would think a game like ZOE2 which has tens of thousands of particles flying around at any one time, and practically based its good looks on the insane amounts of particles and polygons on screen at once, would be difficult to translate properly to Xbox. Sure, the Xbox might be able to display sharper textures and better surfaces, but in the end the look of ZOE2 largely depends on the insane amount of particles moving around, so it would just not feel like the same game.
ZOE2 has slowdowns on PS2, by the way, when the action gets REALLY crazy. Anyone who missed this game, do yourself a favour and give it a try. :D

I really can't think of any other game relying on particles like ZOE2 or Burnout3. Maybe the tanker scene in MGS2. Havent played PS2 games for years.
 
Am I correct in assuming that, to a certain degree, developers get out of a platform what they think they can get out of it?
If they approach the platform with a set of precognitions/prejudices, or have some bad experiences with it in the beginning, that will have a halo effect on the performance they will be able to draw.

PS2 has a pixel fillrate advantage plus eDRAM and xbox has a texelfillrate advantage. The first is a very general advantage and the second a pretty specialized advantage, but if used right can give impressive texture effects, which in turn is exactly what NV2a delivers.
 
Squeak said:
Am I correct in assuming that, to a certain degree, developers get out of a platform what they think they can get out of it?

That's maybe not such a bad assumption.

Right from the start with PS2, writing my first PS2 engine, my team-mate and I were always convinced the machine had a lot of potential and we were determined to get the best out of it no matter how hard it was. Every time we ran into some kind of apparent performance brick-wall, we'd look at the numbers on the specs and say "hey, we're nowhere near the theoretical limits yet - there must be something we're missing...". And we'd go back and work out where the stall was and recode everything around it. We *knew* we could do better, and so we did.

However some other coders I worked with had a bit more of a downer on the platform because they just weren't keen on the system and didn't think it was any good. None of them are bad coders but their results were pretty mediocre at best, because they'd write what they considered to be good code, it'd run "ok" and they'd just think - "well it's not going to get a lot better than that, so we should just leave it like that and move on."

I suppose it would be fair to say that was a product of their expectations and not of their capabilities.

However you also have to factor in the real pressures of a commercial environment. Getting the absolute best out of a platform not only needs developers who want to achieve, but also time in the schedule to put in the extra work. My colleague and I had the relative luxury of about 6 months spent just trying to thrash the hardware - I'm pretty sure that if we'd had to lock down an engine design without that we'd not have been able to make the best of it, even though we'd have wanted to.

(last minute edit:)
It's also worth noting that although we produced something we were happy with at the time, we both know we could do a hell of a lot better now, especially with tools like the PA available - but we're off on seperate teams and not working on PS2 anymore...
 
So the three main factors that encumbers the PS2 is mindset, time and CPU bandwidth?

Would you like to tell us the name of the title you worked on MrWibble?
 
Squeak said:
So the three main factors that encumbers the PS2 is mindset, time and CPU bandwidth?

Would you like to tell us the name of the title you worked on MrWibble?

Mindset and time, in broad general terms, are reasonable.

In technical terms I'd list my top three complaints as:

Lack of a level-2 cache.
Lack of DMA out of VU0.
Lack of multiply blend on the GS.

The first two would most easily boost CPU performance and unlock much more of the PS2's potential - though neither is actually necessary if you hand roll every bit of code! The latter is the biggest failing of the GS if you don't try to compare it to pixel-shader equipped parts. For multipass it needed multiply to be truly useful - without it too much advantage goes to the slower but more versatile shaders...

But something must always give to achieve a deadline or pricepoint (or complete balls-out performance), and Sony built an incredible machine for it's time - it's not every coders cup of tea, but I think I can honestly say I'm glad I coded for it rather than for anything else last-gen. I don't care that a lot of titles didn't look quite as good as similar titles or ports on other machines - because a few titles were truly *unique*.

And actually I prefer anonymity - my employer is not as understanding (or perhaps just more paranoid!) that some. It is easier for me to simply speak for myself and not have any implications for who I work for or the projects I am involved with.

The title in question wasn't a huge commercial success or anything, just something I'm personally quite proud of technically.

Around here, I'm just some guy...
 
Development approach and resources are limiting factors on any system. The opinions about PS2 which were given quite clearly supplied context.

Texel rates are important for building the scene while pixel rates shine best with image post-processing, so a texel advantage would be the one more generally useful while a pixel advantage would have the more specific application.
 
Lazy8s said:
Development approach and resources are limiting factors on any system.
It's a matter of to what degree.
Texel rates are important for building the scene while pixel rates shine best with image post-processing, so a texel advantage would be the one more generally useful while a pixel advantage would have the more specific application.
As said before many times on these boards, singletexturing is still dominant in many modern games.
Large pixelfillrate can be used for plenty more than "just" post processing and multitexturing. Environment maps, shadow maps, stencils, and alpha particles are just few of the possibilities.
 
PS2 particles

london-boy said:
Anyway, in conclusion, yes PS2 is better at particles, so games relying heavily on particles will tend to run better on PS2..

PS2 much better at particles because particles created by VU not CPU. Xbox particles CPU based so its very limited this way.

Same story with animations. Xbox animations CPU based, PS2 VU based.

See State of Emergency conversion document on Gamasutra. Final xbox version with reduced animation load 60fps vs full animation load PS2 version 60fps only 50% of the time but with full animation load, xbox version only 10-15fps.
 
Normal Mapping

MrWibble said:
Lack of a level-2 cache.
Lack of DMA out of VU0.
Lack of multiply blend on the GS.

The first two would most easily boost CPU performance and unlock much more of the PS2's potential - though neither is actually necessary if you hand roll every bit of code! The latter is the biggest failing of the GS if you don't try to compare it to pixel-shader equipped parts. For multipass it needed multiply to be truly useful - without it too much advantage goes to the slower but more versatile shaders...

That coincides with what ive heard. CPU efficiency and VU0 utilization have always been below par and most developers just dont have the luxury of putting the time into getting the most out of these. Its too bad given the potential of the machine no?

Mr. Wibble, curious about what you think of the 4 pass normal mapping theory for PS2? Do you feel its pie in the sky or feasible?

http://ps2dev.org/ps2/Tutorials/TUTORIAL_5:_Advanced_Perfomance_tips/Normal_Mapping_Tutorial_by_Morten_'Sparky'_Mikkelsen
 
ihamoitc2005 said:
See State of Emergency conversion document on Gamasutra. Final xbox version with reduced animation load 60fps vs full animation load PS2 version 60fps only 50% of the time but with full animation load, xbox version only 10-15fps.

Not that simple. You are comparing an unoptimized xbox first attempt against a finely tuned PS2 engine with 5000 lines of hand-built VU assembly.

After optimizations on the xbox to cache duplicate animations and switch to pushbuffers, end result, SOE xbox performance 60fps vs PS2 30fps.
 
Last edited by a moderator:
animations on SOE

Not that simple. You are comparing an unoptimized xbox first attempt against a finely tuned PS2 engine with 5000 lines of hand-built VU assembly.

Unoptimized to architecture, not CPU. They werent running VU code on the XCPU. As for "finely tuned" PS2 engine, thats debatable. SOE looked a little better than a PS1 game.

After optimizations on the xbox to cache duplicate animations and switch to pushbuffers, end result, SOE xbox performance 60fps vs PS2 30fps.

Yes, since the XCPU could not run animation code well enough for each character to be treated independantly, they reduced the animation load by sharing the same animations amongst many characters.

With the original animation load, the PS2 was able to run at 60fps half the time, xbox ran at 10-15fps while 30fps half the time.

Almost the entire "optimization" for xbox was to reduce CPU usage by recycling animations and using push-buffers for the GPU while spreading processing time over 2 frames, to overcome any bottlenecks wherein the CPU or GPU became stalled. Trade-off is the risk of it looking like synchronized rioting but fortunately it still looked pretty chaotic.

The biggest limitation they noted on PS2 was RAM for modelling data and textures.
 
Phil said:
Thank you c0_re for probably ruining a perfect thread that started off quite pleasant and informative.

1.) We really can't judge how well that port was (unless you have performance statistics proving otherwise, which I doubt anyone has)

2.) The scene in MGS2 is a very fillrate demanding scene - which is a strength of the PS2 hardware - so it isn't far fetched to believe that the Xbox would have trouble replicating it.

3.) MGS2 is a game that was developed around the strengths of the PS2 (low texturing, lot of effects like wind, rain etc) - something that on Xbox would not be very good because you can really use great textures, bump-mapping etc.

So even if it was a crappy port, it's still a game that used the PS2 rather well and to it's strength so I'd argue a Xbox version would still have trouble replicating it.

There are examples of other games on Xbox that are developed to that platforms strength (SplinterCell?) which would simply not be replicable on PS2 into the each detail - so this post is really not biased in anyway. It's a logical result of having a different architecture which yields different advantages and requires developers to use different approaches to get the most efficient use out of it.


Did Burnout3 on PS2 support 480p? I don't play any games in less than 480p, 480p is bad enough anything less hurts to look at IMO. I've had a HDTV for over 5 years I wouldn't have even bought an Xbox if 98% of games didn't support progressive scan.

Sorry I didin't know providing my opinion was going to ruin this precious thread, 99% of multiplatform games looked better on Xbox period to argue this point is pointless since it's a matter of opinion and where you put your graphical priorities.
 
Last edited by a moderator:
ihamoitc2005 said:
Almost the entire "optimization" for xbox was to reduce CPU usage by recycling animations and using push-buffers

The pushbuffer optimization is pretty important. Before pushbuffer, you're comparing an engine that goes through the DX API against an engine that just directly writes to the GS. Not a fair comparison.

About having to cache animations to reduce CPU load, fair enough, though I wonder if they investigated how much of the animation system could be moved to vertex shaders (if any).

for the GPU while spreading processing time over 2 frames

That's a normal pipelining technique for generating pallallelism on the xbox. You overlap your rendering command submits for the current frame, and the CPU processing for the next frame, hence, the spreading out of the processing for one frame over two frames.

This is not something out of the ordinary, even on PC.

And considering in this case xbox ends up running at twice the framerate, that's fair.

The biggest limitation they noted on PS2 was RAM for modelling data and textures.

You forgot their issues with the EE's lack of CPU performance for running game engine code and AI.

http://www.gamasutra.com/gdc2003/features/20030307/dobson_01.htm
The nature of the AI engine, and the design of the PS2 meant that this behavioral processing required as much processor time as could be made available. The AI engine did not perform particularly efficiently in terms of data and instruction cache usage. At the most basic level, the AI engine is a loop, with a large amount of complex code to be performed on a different data set, for each iteration. The EE does not aggressively attempt to improve the performance of this sort of code automatically, in the same way that some other processors do. So, if anything, the bottleneck on the PS2 was the AI processing.

[...]

The complete reverse was true on the Xbox. The rendering side of the application was written in DirectX, which is an additional layer of abstraction from the hardware level. This means that the rendering of geometry had a significant CPU requirement, and the same scenes actually took longer, in time, than the PS2 version to render. Conversely the game engine, and the AI code in particular, performed significantly faster without any changes. This was to be expected, since the raw power of the Xbox CPU is arguably higher than the PS2's EE, and the AI code was more suited to Xbox processor.
 
Last edited by a moderator:
Back
Top