It is very unlikely that they had hardware independent assets that were scaled down separately for each console and ended up with almost same game (minus AA), unless of course you think Xenos is basically RSX plus eDRAM goodies.
And don't think I haven't noticed you removed "what's hard to grasp?" part quickly.
I appreciate the edit though.
Why is it very unlikely..?
I think alot of people around here need to learn a little bit about multiplatform development and the wide variety of development practices employed by varying dev companies before they start spouting on about what is "likely" or "reasonable"..
I for one know of several companies who tackle the problem in vastly different ways..:-
- One may have a core team which develop on a "lead" platform and then siphons off assets and preview builds to and external team (whose codebase and content pipeline is already established) either in-house or outsourced, who then work to implement those assets into their version in a like-for-like manner according to the preview builds they recieve.. (Productive, but if the frame work and code base of the secondary platform is provided with "sub-optimal" assets then once production is well under way then code/engine & framework optimisations later down the line are severely limited.. However the solution to this problem would be a "from-the-ground-up" dedicated framework for the secondary platform and a DCC tool exporter to make sure all assets are formatted specifically for their intended platforms.. This requires significant forward planning and sufficient platform experience prior..)
- Another team may setup a complete multiplatform framework which allows the developers to "code-once-compile-many" in a sense where only a single team can work on the game. The art would be exported to a framework specific (as opposed to platform-framework-specific) format and then handled differently by the engine depending on which platform is being compiled to (anyone familiar with XNA would understand a bit about how this process works).. In this vein there is no "lead platform" and both versions are developed, tested and optimised by the same team.. (the biggest draw back is setting up the framework initially is much more intricate and complex and therefore often sacrifices are made with regards to peak performance on one platform for the sake of productivity, safety and robustness (see vector performance on the 360 when using XNA for a perfect example).. This means it's likely that the engine can never fully push a platform like the PS3 for example
unless sufficient fore-knowledge of designing for the architecture is known before hand in order to build under-lying platform specific code which utilises the intricate, non-conventional/uncommon strengths of the system.. However even if this was the case then it still doesn't mean the system could ever draw the full potential of the hardware of any one platform due to the nature of overhead presented by the use of much more generalised higher-level constructs within the framework..)
There are other ways also developers can use to organise productive multi-platform development and the effectiveness of any in all cases is ultimately constrained to the proficiency/experience of the development staff, the nature of the complexity and commonality of the hardware platforms, time, budget etc..
So when it comes down to trying to figure out the reasons why some multiplatform game isn't as pretty on one platform than it is on another, you need to understand that without sufficient information regarding the specific working practices of that particular development team, the answers to such questions can be so vastly varied that it's just insensible to infer the so-called likely-hood of any of them (and especially with respect to what another completely unrelated development house has done in the past..)
