He's a fool and has not got a clue, saying that because HDR is'nt calculated as an FP format its not HDR?
That isn't what he is saying. What he said, in context, was
1. Because it was a port, going with a new HDR technique (like a colorspace format) wouldn't work due to needing to be redesigned.
2. So they have to choose: FP16 based HDR effects which are slower from INT8, FP10, Colorspace (e.g. NOA32), and so forth. We know this, G70 with HDR enabled in games that use FP16 blending and filtering do take a performance hit. So there is a drop in framerate + they cannot use MSAA. Or they can use INT8, gain some framerate back (which seemed to be important to them due to some issues they had
porting their Xenos VS code to RSX), and use MSAA for a cleaner image. So for their deadline and game design it was either FP16 and workout the framerate issues or INT8 with MSAA and alleviating some of their framerate issues.
Now, WHY they are having some of these issues is another story. Some of this is feature based. They are most likely using FP10 on the 360 and RSX just doesn't have a similar format. They may also have used some other features if the Xbox 360 was the lead SKU (probably not stuff like tesselation, streamout, heavy vertex texturing) but it wouldn't surprise me if they were using 3Dc for example for normals. There is always the possibility they are using fairly branchy pixel shaders or may have some heavy vertex work that may not port over well in a limited 2-4 month window; and he already noted the issues they had with the split memory pool.
So if they have a game design where they really wanted MSAA and HDR using a FP format, have tailored their assets for specific features that run a little better on Xenos, and didn't give much though to UMA vs. NUMA, and didn't leave time to resolve these issues during co-development (e.g. NOA32 for HDR, more prortable assets with alternate designs that accent RSX strengths, designed their engine to work equally well with a NUMA design and taking account for texturing from XDR, and so forth), then getting asked to solve ALL these problems during crunch to get performance up to snuff could be very frustrating.
It is no different than the first dev we hear frustrated and dissappointed that his sweet SPE algorhythm spanning 4 SPEs runs at like 20% on 2 Xenon cores, or a game using the PS3 as the lead platform with no/little thought to the 360, and then you try to port all your graphics assets, that may even be using some SPE libraries, and so forth.
One could conjure up many, many scenarios where one of the consoles as a lead platform does a port and where the lead consoles strength was also the design bottleneck, and how that could be a problem on the other console. And yet they are very similar in some ways. The easy solution is to cut/add features as necessary, cut down detail (i.e. cut texture reslution by 50%, so your 720x720 texture becomes 512x512, not a big loss; similarly your 200x200 cloth mesh becomes 141x141), and so forth. This is one of the issues of being 2nd to market: everyone is already full steam ahead building stuff for the other guy, but as development matures developers will do a better job tailoring dev cycles to account for these issues.
And even if joker is a joke, we can see that many Xbox to PS ports this fall did have some issues, especially with getting framerates up. Next fall? It could be reversed.
