bloom crawling in mercenaries 1
#1
Does anyone know of a fix for this? i realise you can avoid it by using software mode but my problem is that performance in software mode sucks. 

I mean, aside from the whiteness. mercs actually RUNS near perfectly for me in direct x hardware mode.
the issue, from what i can tell, is simply that the depth buffer does not appear to clear in between frames, allowing the post-processing effects to keep reapplying to the screen unhindered, causing the bloom to generate its own bloom eventually crawling across the screen.

Does anyone know of a way to force it to clear the zbuffer before every frame? even if i have to use an external program to force it?
Reply

Sponsored links

#2
Switching to software mode with F9 then back again to hardware mode with F9 should clear it
[Image: newsig.jpg]
Reply
#3
(03-04-2016, 12:48 PM)Bositman Wrote: Switching to software mode with F9 then back again to hardware mode with F9 should clear it

true, but alas it only clears it once. and takes a few moments (the bloom crawl covers the screen in a few seconds)
Reply
#4
you could try using the skipdraw setting under gsdx hw hacks, just don't forget to enable hw hacks too Smile

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.
[Image: ref-sig-anim.gif]

Reply
#5
(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 Smile

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
Reply
#6
Try one of the new builds, they offer some speedups for the accurate options of OpenGL: http://buildbot.orphis.net/pcsx2/index.php
[Image: newsig.jpg]
Reply
#7
(03-04-2016, 03:21 PM)Bositman Wrote: Try one of the new builds, they offer some speedups for the accurate options of OpenGL: http://buildbot.orphis.net/pcsx2/index.php

thankyou for the tip! i will give this a shot tomorrow as it is now past midnight and i have work in the morning. but when i do get a chance to try it i will let you know of the outcome!
Reply
#8
ok, i have downloaded the latest build to test the opengl modes my apologies, it turns out hw opengl is doing the same thing too with the bloom crawling and whatnot, and software open gl i can get running at around 95% speed with some dips down to 80 (so long as the ee cyclerate set to 2). a problem with the software mode (dx9, dx11 and opengl) is that there are lines all across the screen (super distracting)
http://i.imgur.com/CS8BQ7x.png
its more noticeable in urban areas
Reply




Users browsing this thread: 1 Guest(s)