PCSX2 / pcsx2

PCSX2 - The Playstation 2 Emulator
https://pcsx2.net
GNU General Public License v3.0
11.82k stars 1.63k forks source link

Prince of Persia Warrior withing not rendering correctly #318

Closed SerialHacker closed 5 years ago

SerialHacker commented 10 years ago

1st Response from GSDX Hardware mode : Nothing rendered

2nd Response from GSDX Software mode : "GSdx: out-of-memory, texturing temporarily disabled" ( fixed using NTCore 4GB patcher)

3rd Response from GSDX Open GL : Rendering almost perfectly, but ofcourse low performance.

gregory38 commented 9 years ago

A test with GSdx texture cache disabled would be a good idea (I don't see any valid reason that the game is working with OGL backend)

gregory38 commented 9 years ago

Please try the version from this thread: http://forums.pcsx2.net/Thread-GSdx-2-0 OpenGL only

Someone reports some info on a Prince of Persia but not sure it is the same version.

Normally there is still a wrong overlay on OpenGL but if you look carefully the top-left corner might be correct. If it is also the case here, it is a limitation of the texture cache.

bositman commented 9 years ago

This one is very broken. DX11 HW with CRC hacks Full shows a black screen (possibly old broken hack?) , CRC none gives a blue tinted full screen effect and ~70 FPS on native

OpenGL HW with CRC hacks None or Full gives me the same screen like DX11 HW (all blue) but top left corner looks correct, at 3 FPS (!!) on native.

DX11 and OpenGL SW renderers work fine and faster than HW, no out of memory errors, I guess got fixed by https://github.com/PCSX2/pcsx2/commit/49b3acea72a4c2a37811a4616cb2d940355b6952

GS dump: http://bositman.pcsx2.net/dumps/prince-of-persia-warrior-within.rar

gregory38 commented 9 years ago

OoO The remaining issue is a texture cache issue.

However it is strange that DX11 is faster. Dx will do the texture conversion on the CPU whereas GL will do it on the GPU. Maybe your GPU vram is full. Anyway, on the future I will likely bypass the conversion. It will fix issue&slow down in one shot.

SerialHacker commented 9 years ago

I've been giving feedback in the Forums, you should have noticed that the username is the same :P

bositman commented 9 years ago

You should give complete reports, not bits and pieces here and there. And the github issue tracker is far better than doing it on the forum.

SerialHacker commented 9 years ago

BTW your VRAM getting maxed out is what causing the black screen in DX11 HW.

bositman commented 9 years ago

My VRAM is maxed out with CRC hacks to none as well, where I do get the blue screen output, so no that's not it.

gregory38 commented 9 years ago

The black screen is due to bad support of write rgba read as 8 bits palette index. The blue screen is due to a texture cache bug.

gregory38 commented 8 years ago

Latest git ought to fix remaining issue with openGL.

ghost commented 8 years ago

DX11 software renders fine. DX11 hardware renders black screen with only some top-left UI part visible. OGL software renders fine. OGL hardware renders almost fine. The top half of the screen is good, the bottom half (split in the middle horizontally) renders with a strong greenish tint (green-and-white?). None of the settings seem to affect this.

Video: https://vid.me/fbcM

Radeon 6850 with Crimson legacy 16.2.1, Windows 7 x64, no error messages in the log. Tested version: v1.5.0-dev-914-g185012b (2016-06-19 12:48:11) automated git build from here: http://buildbot.orphis.net/pcsx2/index.php

FlatOutPS2 commented 8 years ago

@ghost Can you check if OGL hardware still has the green tint on the bottom half of the screen with the one of the latest GIT releases?

bositman commented 8 years ago

Seems ok with current OpenGL ;)

FlatOutPS2 commented 8 years ago

Seems ok with current OpenGL ;)

Does that mean this issue can be closed or is there a remaining issue?

avih commented 8 years ago

Does that mean this issue can be closed or is there a remaining issue?

You mean other than the fact that many PCSX2 users can't use it because for them OpenGL is a lot slower than DX?

FlatOutPS2 commented 8 years ago

You mean other than the fact that many PCSX2 users can't use it because for them OpenGL is a lot slower than DX?

The lack of OGL speed is not a PCSX2 issue(well mostly not), let alone an issue that's specific to this game.

I'm assuming DX doesn't work because of the lack of hardware depth/blending, or is this an issue that can be fixed for DX?

avih commented 8 years ago

The lack of OGL speed is not a PCSX2 issue(well mostly not), let alone an issue that's specific to this game.

In that case, you might as well suggested to test it in software mode, or interpreter if speed is not an issue you concern yourself with. And yet you suggested OpenGL as a potential solution, while ignoring the fact that it doesn't solve the issue for many PCSX2 users.

FlatOutPS2 commented 8 years ago

In that case, you might as well suggested to test it in software mode, or interpreter if speed is not an issue you concern yourself with. And yet you suggested OpenGL as a potential solution, while ignoring the fact that it doesn't solve the issue for many PCSX2 users.

Yes it does. They can play the game in OGL Hardware mode. If this causes any speed issues it means they either have outdated hardware or they're AMD GPU users and have to wait for AMD to resolve the OGL driver speed issues. In either case it is not an issue specific to PCSX2 or this game.

avih commented 8 years ago

or they're AMD GPU users and have to wait for AMD to resolve the OGL driver speed issues.

In other words, you just admitted your suggestion is not really practical for AMD users, and yet you considered closing the issue is if works in OpenGL.

In either case it is not an issue specific to PCSX2 or this game.

We can go on forever, but we must face the fact that OpenGL in PCSX2 effectively/practically excludes a lot of PCSX2 users - People with AMD GPUs, and has done this for a long time now, for whatever reason which might or might not have good justification.

The issue is clearly a combination of fidelity and performance, or else people would just use software mode, not concern themselves with speed, and everything is great. So for this combined issue, OpenGL does not currently provide a solution for people with AMD GPUs.

You might as well close any bug report on OpenGL because it works in software, for exactly the same reasons.

FlatOutPS2 commented 8 years ago

In other words, you just admitted your suggestion is not really practical for AMD users, and yet you considered closing the issue is if works in OpenGL.

No, you're at your usual practice of using someone else's words and applying them to your own aggravated vision. OpenGL works fine for many AMD users, even if OGL is not as fast as DX all the time, in many games it doesn't affect the speed so much that it can't be played at 100% at at least 3x native(including this one). But you can reopen over 200 issues that were resolved, but by a solution or option that can noticeably slow down the emulation or were resolved only in OGL HW if you really want to.

This issue was about two problems. A memory bug in SW mode made that mode unplayable and a hardware mode graphics issue that made the playing in hardware mode impossible too. The software mode issue has been resolved and the hardware mode issue can be resolved by switching renderer.

avih commented 8 years ago

OpenGL works fine for many AMD users, even if OGL is not as fast as DX all the time, in many games it doesn't affect the speed so much that it can't be played at 100% at at least 3x native(including this one).

If this game works fine in OpenGL for AMD users, then OpenGL a good solution indeed. However, unless the OP says otherwise, so far the comments (at this issue above) suggest that it runs very slow with AMD+OpenGL, and I'm not yet seeing comments that the speed has improved at any stage.

gregory38 commented 8 years ago

Avih, you pick up the wrong war man. Flatout has an AMD gpu (with a legacy driver), he knows it isn't perfect but still playable. Mirh opened an issue on the AMD forum. And they identified an optimization (likely a basic one) possible with separate shader object (aka SSO, aka don't validate the vertex shader when only the fragment shader is updated). Of course, AMD will need 6 months to release it and they will likely need more optimizations. Hopefully we might win 2-10 fps.

Anyway, gsdx openGL port was done for Linux user in the first place. Most of Nvidia Win users are quite happy about it too. And some AMD users too. The fact that AMD said they support fully openGL but provide a limited/buggy driver is an AMD issue.

IMHO, all applications try to find workaround so bugs on the drivers are never fixed. Instead to complain, Mirh does a wonderful job to report bug to AMD. AMD did a fix for SSO. They working to improve the perf. They also working a blending crash regression.

refractionpcsx2 commented 8 years ago

That's one big thing I've got to give AMD, they are really receptive to bug reports and the interaction with the devs and community is great.

MrCK1 commented 8 years ago

Can someone check DX11 status so I can close a bug report? Wiki page also needs an update :)

Thanks FlatOut ;)

feikname commented 6 years ago

Current status with latest master (1c58d5acffb6186d394feae524e9774a8d77b772) is that OpenGL on hardware works as expected but Direct3D11 on hardware seems to have the color space somehow messed up.

image

Tested with Intel UHD Graphics 620 and Raden 530.

lightningterror commented 5 years ago

Fixed with depth emulation and channel shuffle port on d3d11.

Also duplicate of #1318