(06-17-2014, 05:36 AM)JMC47 Wrote: I was slightly wrong, D3D has always had the bug in EFB2RAM. 1x IR is correct on both backends, 4x IR on OGL with EFB2Ram set is also correct. 4x IR in D3D and 4x IR in OGL in EFB2Texture are glitched. D3D has no differences between EFB2Ram and EFB2Texture.
D3D 4x IR - https://dl.dropboxusercontent.com/u/484730/D3D4xIR.png
D3D 1x IR - https://dl.dropboxusercontent.com/u/484730/D3D1xIR.png
OGL 4x IR EFB2RAM - https://dl.dropboxusercontent.com/u/4847...FB2Ram.png
OGL 4x IR EFB2TEX - https://dl.dropboxusercontent.com/u/4847...FB2Tex.png
GL bug spotted
![Smile Smile](https://forums.dolphin-emu.org/images/smilies/smile.gif)
I think you took it the wrong way. To start with, the game is doing a bloom pass running on a dozen of steps ( render blooming elements in white on black, efb copy scaled by half, quarter res quad with several blend/blur in place, efb copy scaled by half means 1/8 target, 1/8 quad blit then in place blend and blur, efbcopy, merge the 1/8 and 1/4 version into an 1/4 res, efbcopy and finaly restore the frame blended to the bloom ).
It is possible that some passes suffers more from a scaled IR with the offsets use in the texture fetches and it may even be possible that we have issues with rasterisation/texels centers, but if you look closely, the supposed good efb2ram GL version have a bloom resolution similar to the 1xIR. That means that the EFB2RAM GL build have a bug that prevent it to use the 4xIR efbcopy texture and upload it instead from ram, dropping the extra resolution at the same time. That effect is clearly GPU only and there is a 0% chance that the cpu is touching the memory here.
GL bug spotted
![Smile Smile](https://forums.dolphin-emu.org/images/smilies/smile.gif)