(03-04-2016, 01:43 PM)refraction Wrote: you could try using the skipdraw setting under gsdx hw hacks, just don't forget to enable hw hacks too
Start with setting it to 1, if that doesn't work try 2, etc etc.
You could also try OpenGL with the blending unit accuracy turned up until it fixes it.
when using skipdraw, the only setting i could find that 100% completely stopped the bloom issue is skipdraw 100, however all this did was highlight the underlying issue of the zbuffer
http://i.imgur.com/jeJycQ1.png?1
as you can see here (from my running around in circles) the issue is pretty bad. what is happening here is that once a pixel is drawn and given a depth value it never has that depth value erased before the next frame. so when the next frame is being rendered, a pixel wont be drawn if the object is further away than the stored depth value of the pixel.
USUALLY this is to prevent system resources being spent drawing a pixel for something that exists behind an opaque object, as that pixel will be redrawn for whatever is closest to the camera (you cant see through objects so why render anything behind them).
but what is happening in this instance is: because the pixel depth information is not being erased, when the renderer goes to draw something new, it thinks those objects are still there and says "im not going to draw this as its behond something" despite that not being the case.
you will notice that the HUD in that image is unaffected. this is because the hud is ALWAYS drawn on top, regardless of the 3d world behind it and as such is immune to these issues. the bloom, however in THIS image:
http://i.imgur.com/lLtGgjw.png?1
This is happening because of the following process:
1. first frame is rendered
2. post processing takes the frame and applies bloom to the bright bits
3. next frame attempts to be rendered (but no new pixels are drawn so the previous frame's bloom remains)
4. the post processor comes along and applies the bloom to the bright bits (over the top of the previous bloom)
5. repeat steps 3 and 4 a few times
6. the post processor comes to apply bloom, but because the previous bloom was layered repeatedly, its now bright enough to warrant its own bloom (bloomception)
7. ect ect untill the screen is white with bloomageddon
as for open gl. it does not actually have this issue and actually looks like it should. BUT on default emulation settings runs at ~2% speed, and with all the tweaking i could do i managed to max out opengl at ~35% speed (whereas direct x runs at ~100% on default), so open gl is a no go for this game