I did not know this, can someone explain to me in more detail how can the 360 manage to only use 7MB back buffer compared to the 30MB the PS3 uses for 1280X720 4xAA.
That's what tiling is all about. Instead of generating all the data (samples in this case) that needs to processed (resolved) and doing the processing after that, you generate part of it, process that part and repeat those two operations for other parts. Thus your memory requirement is mostly dictated by "part" as opposed to whole as you can reuse the same memory space for generated data (samples).
You can do pretty much the same thing on PS3 as well, if you can live with the additional cost of tiling that is.
I am up for it, great idea. A joint collaboration between Mazingerdude, grandmaster -yes, DF knows all and tells all....- and Nebula would be truly nice.
Also the framerate differences between each of those different settings and with what settings it's easier to obtain the awe-inspiring 60 fps in games without affecting visual fidelity that much!
Dunno how I missed that but sure that could be done. Maybe HL2 CM, UT3 or FC2. Though I remember I did something similar with FC2 some time ago and lower res with upscaling + higher settings came of better than higher res + medium settings. Though my monitor only allows captures to 1680x1050.
EDIT: Well used FC2 but the texture settings dont scale linearly. Anyway done is done. ~1680x1050 (game limits my res options), uscaling method bilinear. All DX9, max but different texture settings, MSAA and AF (min 2xAF as game dont allow me to turn it of nor ATI CCC).
You might wanna recheck the first set of pictures.
The first image is definitely running at a lower resolution than the 2nd image its blurry & looks upscaled compared to the 2nd image which is crisp & doesn't looks to be upscaled.
At 4xmsaa, you need to store data for 1280x720x4 pixels, or 3686400 pixels total. For each of those pixels you need both color and z data each of which is typically 4 bytes/pixel. So if you need 8 bytes/pixel then it comes to 3686400 * 8 = 29491200 bytes total, or around ~28mb needed to store the temporary msaa data. On PS3 there is no scratch memory space so that 28mb eats up part of the 512mb of memory that it has.
On 360 the overall total amount of memory needed to complete the 4xmsaa process is identical, 28mb. The difference is that it takes 0mb of the main 512mb of memory because the 10 edram memory is used. You render it as multiple tiles, so instead of rendering it as 1280x720x4, you render it in three parts:
1) 1280x256x4
2) 1280x256x4
3) 1280x208x4
Assuming again 8 bytes per pixel means that tile #1 above needs 1280x256*4*8 = 10485760 bytes, which is exactly 10mb. Because it's all done in edram, that means that 0mb of the 512mb of memory is needed to do msaa on 360. In otherwords, all things being equal if you use 4xmsaa on both PS3 and 360 versions of the game, then you will need to free up an additional ~28mb on the PS3 version to make it fit into memory.
Dunno how I missed that but sure that could be done. Maybe HL2 CM, UT3 or FC2. Though I remember I did something similar with FC2 some time ago and lower res with upscaling + higher settings came of better than higher res + medium settings. Though my monitor only allows captures to 1680x1050.
EDIT: Well used FC2 but the texture settings dont scale linearly. Anyway done is done. ~1680x1050 (game limits my res options), uscaling method bilinear. All DX9, max but different texture settings, MSAA and AF (min 2xAF as game dont allow me to turn it of nor ATI CCC).
Many thanks Nebula. Well, it seems like I made a deal with you :smile:. Your passion to play with these kind of settings is so special.... I am thankful for that. It's been a while since I started wanting to do something similar and I still can't decide exactly when I could begin to try. I wanted to play with the settings in some PC games until fairly recently when I realized I don't have the PC suitable for one....
I know I shouldn't be asking other people how to modify settings and trying something that I can't do myself but I'm completely ambivalent as to which way is better in order to know the differences, and what those settings imply in terms of performance and image quality balance.
Now with the pics.., I will state my preference since I have been looking at the images quite a few times to make sure I've made the right choice, in my opinion.
For the first set of images I'd go either with BVC or KLM in general -of course nothing beats the WWSN pic (1680x1050, maxed out) but those two aren't as blurry as the others-.
I say BVC, the top. Getting the middle ones as reference the game would look unbalanced, great in some areas but too blurry in others. However, the upscaling might have played a factor.
IUY is some kind of wtf-ish image, it looks rather odd. It's just a little too blurry for my taste. Between RTS (1152x648, I half wonder how can you choose this resolution on the PC) and KLM pics, I'd go with KLM -the 720p one-, and my second favourite overall since it looks crisper, especially the ground and road surface, plus the roof. The high quality textures don't make up for the loss of resolution in the 648p pic.
Of course WWS looks way better but it's not fair. Anywhere you play it will be cool, you just wanted to get that screenshot in the most flattering manner, haha.
It would be great to know the framerate differences between those settings, or the settings that get the closer framerate balance and performance to make a fair comparison. I.e. 1280x720, 0xMSAA, 2xAF, medium textures (KLM pic) or the 848x480 ,4xMSAA, 8xAF, ultra high textures settings. This would be material for a DF article I think, taking into account the means they have. I think it would be a good idea if grandmaster could get in touch with you if Eurogamer finds the article interesting. In fact, I think he credited you in some of his articles, if I remember correctly.
In my sight, the differences between screenshots in the second comparison are far less pronounced over all. F2CD looks horrible despite featuring the highest quality settings, only the tree leaves look a lot better, but you can notice the loss of detail fairly easily.
The blurriness distracts me a little from the aesthetics of the game.
The differences between the FC2B -720p- and FC2C -1158x648- aren't as noticeable as in the previous comparison. Still the tree leaves in the 720p image looks sharper despite of the settings, where the 648p pic has the edge here.
The light blue wall texture on the little warehouse looks sharper running at 720p than at 648p. Still the 1680x1050 pic looks better, no upscaling involved.
Thanks for sharing Nebula -really nice people-.
Anyhow, this was a symbolic step towards a journey of reclaiming the possibility to change settings and how they alter the visual perception of the game, and what are the developer choices, and thank you for participating.
I'm not quite sure why the article says it takes 7mb on 360 though. On both machines you need a final 1280x720 buffer to resolve to, which would be around 7mb in size, but I don't know why they include that figure on the 360 memory total but not on the PS3's. If you go by just memory needed for 4xmsaa, then it's ~28mb on PS3 and 0mb on 360. If you include the final resolve buffers into that then it's ~35mb on PS3 and ~7mb on 360.
hm... I thought it had to do with them packing normals and depth into a single RT in the first pass. Resolve to main mem as 3.68MB. Then you have the lighting pass for the "second 3.68MB". Did you get a chance to check the ppt on their version of light pre-pass/spu lighting?
I'm a bit surprised at the LP2 comparison.. well the variable frame rate was apparent in some chapters, but I thought it ran considerably better than RE5 on PS3 (which aside from some hectic scenarios in the assembly, it wasn't bad). I guess the whole triple buffered/v-sync vs. double/without thing balances out. Thankfully, QAA was ditched and that's what really bothered me with RE5 alongside dumbed down water, which isn't the case here.
Curious though, since triple buffering uses more memory, why wouldn't they opt for a similar setup at the 360 rendition? Perhaps they felt the pros and cons of the different setups balanced out?
Though watching the video, that one akrid fight (chapter 1-2) was fairly consistent in both versions and I felt that the area pinpointed the variable frame rate best.
I remember from playing the early lp2 demo for ps3 there was absolutely massive amounts of tearing, this is probably why they triple buffered. O wish they delayed the game and improved framerate
The PS3 demos had uncapped frame rates which elevated the tearing; it really stuck out in the multiplayer demo. That also dropped down to 15Hz at times so it was a different case altogether and the controls took a dive. Check out the analysis vid to get an idea of the final game.
Like the article suggests, performance is mostly identical between the two. One tears when stressed and the other drops frames instead, both on varying levels depending on the stress. It's most noticeable in the train station akrid fight on both. The tearing can creep up to the middle of the screen and the PS3 game drops to low 20's.
The article does not suggest performance is identical at all (either in writing or the videos). While the 360 occasionally tears the PS3 has a consistently lower framerate - very frequently dipping below 30 even when the 360 doesn't tear. Another baffling choice of a triple buffer....
I remember from playing the early lp2 demo for ps3 there was absolutely massive amounts of tearing, this is probably why they triple buffered. O wish they delayed the game and improved framerate
I agree using triple buffering is necessary on PS3 since it has problems maintaining 30 frames in all of the intensive scenes, it would cause an unacceptable level of screen tearing with a soft VSync.
In the like-for-like video of the initial arrival for example, 360 seems to maintain 30FPS fairly effortlessly, but PS3 struggles rendering what is the exact same scene (sans anti-aliasing).
While performance is often parallel between the two systems, PS3 drops frames much more frequently than 360 tears. We saw exactly the same thing in Resident Evil 5, and while it seems Capcom has improved a touch since then, it's still extremely off-putting.
Well, it would be prudent to consider the pseudo 30Hz limiter on 360. We have seen it so many times in the past articles... one wonders if that is adequate.. and "simple enough" to use sans triple buffer. Humm..................
I wonder that myself, unless they've explored that option at some point. Either that, or someone on the team really hates tearing. The RE5 team mentioned that triple buffering wasn't used on the 360 because of memory limitation of the eDRAM. Really vague and didn't make much sense at face value. What did they mean?
Also, how much more memory triple buffering burns compared to double buffering?
Well, I did say mostly identical, and the vid does suggest that to an extent:
While performance is often parallel between the two systems, PS3 drops frames much more frequently than 360 tears. We saw exactly the same thing in Resident Evil 5, and while it seems Capcom has improved a touch since then, it's still extremely off-putting.
It's in those scenarios where it drops below 25Hz that it becomes cumbersome. Especially since the game itself has some peculiar controls with traditional Japanese quirkiness that's typically associated with fighters and action games. Thankfully, those are rare enough, and I'd consider this the best MT Framework effort second to DMC4. IQ wise, it's easily the best due to the lack of temporal AA or QAA.
Given what it is, I'm more than content with the balance between the versions this time. With RE5, the frame rate was consistently lower in most scenarios, the QAA implementation stunk, some missing particles in 2-3 scenarios, and the water in the large body of the wetlands.. well, here's what it looked on the PS3:
It looked like that but it's not off that version. I got off a Game Watch feature, and those pics were used to demonstrate how the water was rendered. This is how the final 360 water looked actually:
