Some plugin without bug?

[Paulocj]

For mercenaries..
the latest versions of pcsx2 FPS is OK in hardware mode, but, some glitch, software mode have no glitch's but FPS low in my pc.
Sorry for my english, i'am Brazilian..
OpenGL plyugin only half of the screen is bugged, hardware mode all screen glitched (if it help in something)

[jesalvein]

In order to help you further with your problem, please make sure the following are all provided.

• Your hardware specs - CPU, Graphics Card, Memory, Operating System.
  
• The version of PCSX2 you are using.
  
• Any non default settings you are using.
  
• What games you are trying to play and if you are playing them from ISO or DVD.
  

Thank You.

[Skohix]

Pc Specs:
Windows 8.1 Pro 64-bit
Intel i7 4790k 4.00 Ghz
OC Nvidia Asus Strix Gtx 980 4GB
16GB Ram
Direct X11
OpenGL version 4.4

Pcsx2 Version:
http://buildbot.orphis.net/pcsx2/
V1.5.0-dev-769-gdf5035d

Settings:
http://postimg.org/image/q97b2d7dd/full/

Game:
Mecenaries: Playgrounds of Destruction, in iso 

Extra info:
Have been testing it more with the latest builds, its nice that it starts a new game in OpenGL instead of crashing but now half of the screen turns white (with Dx 9 and 11 the whole screen would slowly start turning white). Game seems to run fine for me though, it is just the half of the screen turning white for some reason.
I also get a blue text in the console saying "MsManager garbage collection...." when starting a new game, i do not know what that means.

[gregory]

It is a known issue. Lots of game suffer from it, and it would take some times to fix them. https://github.com/PCSX2/pcsx2/issues/1339

[FozzieOscar]

For mercenaries..
the latest versions of pcsx2 FPS is OK in hardware mode, but, some glitch, software mode have no glitch's but FPS low in my pc.
Sorry for my english, i'am Brazilian..
OpenGL plyugin only half of the screen is bugged, hardware mode all screen glitched (if it help in something)

from what i can tell (i have the same issue in mercenaries as well) its an issue with the depth buffer.
the top half of the screen is functioning as per normal, testing the depth with each new frame and rendering accordingly
the bottom half is doing something else, and as a result, bloom bleeds across it.

it used to be a case that the whole screen would do it, never rendering new pixels unless they were considered "closer" than the previous frame, allowing bloom to cover the whole screen as the post-processing effects are always applied directly to screen elements regardless of distance. (you can still see this issue with the direct X hardware renderer)

although exciting that we get to see it working correctly on the top half now, the bottom row is still producing this issue to a certain extent

Note: interestingly turning on the "Disable depth emulation" returns this issue to being a full screen one, but if you ALSO turn on the "preload data frame" option, it almost completely erases the issue (the bottom half of the screen is slightly darker) but poses a new problem, the distance fog no longer gradually affects disability, functionally reducing your sight radius to ~20 meters

edit: the lower half screen problems, although producing the same issues as the zbuffer problem (bloom crawl), appears to be exclusive to the bloom itself as the geometry is rendering properly with certain, very high skipdraw levels. i can get it KIND of working with skipdraw 100, however i get different issues such as random but frequent full-screen flashing (think lightning flashes from a storm, but obscuring the screen with what i can only describe as multi-coloured static)

[gregory]

I know the issue. It isn't limited to depth buffer. The issue is that games use a pointer to half frame. The trick is to detect the half frame rendering. Then it's just a matter to use the real start of frame + a vertex position offset.
I'm not in the mood to fix it now but maybe on the future

[FozzieOscar]

I know the issue. It isn't limited to depth buffer. The issue is that games use a pointer to half frame. The trick is to detect the half frame rendering.  Then it's just a matter to use the real start of frame + a vertex position offset.
I'm not in the mood to fix it now but maybe on the future

lol you know ALOT more about this stuff than me!

i had prepared a screenshot for reference, one taken before the bloom can spread much
ill add it anyway just because i think its a good visualization of what is happening

as you can see, the stripes conform to the shape of the roof, marking certain increments in depth from the camera's position which lead me to (falsely, im now aware) think it was z-buffer related

if you do take this problem on board, good luck! i cant wait to play this game again without slowdowns or graphical glitches!

[gregory]

I don't know everything. But I already studied a couple of GL traces to analyze similar issues. There is 2 GSdx limitations actually. Just saying that you don't spend too much times to find some workarounds.

You're right, it is kinds of related to the Z buffer (depends on the game, 40 games are impacted). On GS, you only have memory pointer not buffer inside memory. Unlike GPU buffer, there is no start, neither end of the "buffer". It generates tons of issues. Trust me, it isn't limited to this one.