[Bug Report] Metal Gear Solid 2: Substance [NTSC-U]

[ssakash]

_PCSX2 versions used:_ pcsx2-v1.3.1-1256-gbbd74e5 (latest dev build) _Emulation settings:_ "Safest" preset, no hacks. _Plugins used:_ GSdx AVX2 using all renderers. _Plugin settings:_ CRC Hack Level "None"

Description:

On hardware mode, when the thermal goggles are equipped, the obtained screen effect is broken and appears to be resource intensive; it seems like the last layer which shows the heat map is only shown minimized to the top left corner. The resolution of the corner also appears to be different from the rest of the screen. On software mode, it works as expected.

The following bug only exists on D3D9 , D3D11 , OGL (Hardware mode). // haven't tested OpenCL

Hardware Specifications :-

CPU: Intel(R) Core(TM) i5-4690K CPU @ 3.50GHz

GPU: NVIDIA GeForce GTX 970 (Driver: NVIDIA 358.50)

Screenshots:

OpenGL renderer. No character shadows and no scanline overlay.

Software mode output, expected result :

_GS dump_ : http://forums.pcsx2.net/attachment.php?aid=57417

[refractionpcsx2]

This is a texture cache problem I believe. I vaguely recall Gregory saying the game issues the post processing event in small chunks and repeats it across the screen. Implementing it would be very slow unless we can think of a super craft way to do it.

But this is why the top left corner is correct and the rest is not.

[gregory38]

Yes the game does a rendering into tiny box (64x32 pixels).The texture cache reference targets by their start address. Therefore only the first "box" is correct. It also explain why those games eat all the memory. Each tiny box consumes a full RT 2Kx1K pixels...

I have several ideas to implement this kind of stuffs. It is doable but it is difficult. Potentially a good (hackish) implementation could even be faster than the current situation. Maybe we just need to detect the top left-corner case and extend it to the full sceen. Then we could drop the N consecutive draw call.

[refractionpcsx2]

That would be good :) What about implementing flexible RT sizes so it's only the texture size * multiplier (obviously custom res can go screw itself)? that would save a ton of memory in these games that do tons of tiny textures (im looking at you Baldurs Gate)

[gregory38]

RT doesn't really have size. RT is just a pointer. The only value that you have is W, and it doesn't mean anythings. Hum, however Gabest implements some stuff to find the min/max of x/y value. It could help.

RT[ y * W + x] = value

Anyway, you can't draw in a small RT because you don't know the size of the same RT in the next draw calls. (well we can still extend it but I'm not sure we have time)

BG is another story. The issue isn't the tiny texture (8bits texture solve most of it). The issue is that the game copy a sub-part of the RT into a tiny texture. It triggers a GPU=>GS transfer which is very slow. Potentially, TC keeps useless data in memory so I think it can be improved. Hum, I'm curious of what will be the behavior if we drop the GPU=>GS transfers as a speed hack?

diff --git a/plugins/GSdx/GSTextureOGL.cpp b/plugins/GSdx/GSTextureOGL.cpp
index 75d0c7f..68841b7 100644
--- a/plugins/GSdx/GSTextureOGL.cpp
+++ b/plugins/GSdx/GSTextureOGL.cpp
@@ -389,6 +389,7 @@ bool GSTextureOGL::Map(GSMap& m, const GSVector4i* r)
 {
        // LOTS OF CRAP CODE!!!! PLEASE FIX ME !!!
        if (m_type != GSTexture::Offscreen) return false;
+       return true;

        // The fastest way will be to use a PBO to read the data asynchronously. Unfortunately GSdx
        // architecture is waiting the data right now.

Anyway, in debug mode, openGL print the memory consumption of each texture pools. Maybe we could print it only this information (otherwise it is really verbose) to see where the memory is really consumed.

If I come back to the sub RT support, here a list of what can be done 1/ do post-processing in place. Current situation is a/ convert the RT into a texture T (potentially resize it) b/ do the drawing from T to RT On the future why not draw from RT to RT. (i.e. directly sampling the RT). It could really help the performance because it would reduce the jobs of the texture cache. T is used only once so no need to cache it, no memory allocation no silly hit. As a side note it might require a better support of 8 bits RT.

2/ Support offset or extend the vertex size. a/ offset will just add an extra offset to the vertex. This way we can keep the same RT located at address 0. b/ Or, just draw a fullscreen quad instead of a small tiny box.

[Blackbird88]

Not fixed and same issue as MGS3 codec. High VRAM usage. I assume they are same problem.

[Blackbird88]

Fixed in @9cacfee for OpenGL backend.

[GatoSnake]

Hi! .. actually I have the same problem reported here, I am using the last version PCSX2 v1.4.0, with default setting.

I don't know what is the problem, please help me! :)

[Blackbird88]

Simple. You need latest nightly https://buildbot.orphis.net/pcsx2/index.php And you need to select OpenGL in GSdx. D3D11 isn't getting most of the new fixes.

[gregory38]

And probably without custom resolution (which must be different than the screen resolution).

[GatoSnake]

thanks @blackb1rd and @gregory38 for your answer. Yes, I must download the latest versions of pcsx2, but now I have another issue using OpenGL.

The description is here https://github.com/PCSX2/pcsx2/issues/1339

[QuakeGamer632]

I hate to necro but I am at my whit's end here, I have downloaded the latest build from Orphis and tried switching between DirectX and OpenGL and nothing seems to help at all (besides software render which turns the game into a blurry mess). All the same stuff, thermal goggle vision is green and black with the blue and red stuck in the corner. I could see that every time I use thermal goggles it makes my VRAM usage shoot from 1.5GB up to the full 6GB my card has.

The issue is marked as resolved but doesn't list a solution other than "use OpenGL" which has changed nothing for me.

[Blackbird88]

AMD GPU?

[QuakeGamer632]

No, nVidia GTX 1060 6GB, i7-7700K, 32GB DDR4.

[refractionpcsx2]

What is your blending accuracy set to? And did you make sure you're using the AVX2 build of gsdx?

[QuakeGamer632]

Blending accuracy I have used at both basic and medium, neither makes any difference.

And I've never even heard of AVX2 so unless that is default then no I'm not.

[refractionpcsx2]

ok in that case can you go in to Configure -> Plugin/BIOS Configuration (my wording might be off here, but you'll get what I mean when you see it) and then make sure you're on the "Plugins" tab and see what the GS plugin says at the end. If it doesn't say "Gsdx32-AVX2", can you change it to the one that does?

This may not make a difference, but I want to be sure you aren't using an old plugin that hasn't been updated with the fixes for MGS.

Then of course make sure you are in OpenGL mode. You may need to try different Blending Accuracy settings, I'm not sure which one would solve it. Oh and make sure your CRC level is set to "OpenGL (Recommended)"

[QuakeGamer632]

Ok so I have actually made progress, not sure how I never found out about AVX2 in my four or so years of using PCSX2. So now I am having the same issue that Crismaster had, bottom half of the screen mostly goes black but it also has other weird graphical issues depending on where I have the camera. Is there any fix for this issue yet? Looking through the page Crismaster posted I didn't see a solution to it just that it was mentioned.

Thanks a lot for helping though, not often you find an older post like this and actually get a response.

Edit: Another image that shows it off a little more obviously. (CRC is set to auto and using OpenGL HW)

[MrCK1]

Did you switch to OpenGL and have your CRC hacks set to Automatic?

[lightningterror]

Yeah that's a half screen bottom issue. #1339