The 3rd Birthday graphic problems (RetroArch Windows)

[ToniBC]

With the Libretro version in Retroarch, everything updated to nightly, in Windows 10 x64 under Vulkan or GL.

(Fixed) The letters or menus of the game have a slight tremor.

During the game it appears as an overlay image, as if it were dirt on the screen, it is like a still image.

I have tried the options, both by default and alternating between them, but found no solution.

In the nightly version of PPSSPP Standalone that does not happen, it looks good without those errors in the letters or menus and without the superimposed image.

Does anyone have a solution?

[i30817]

Turn on frameskip 1 and try again.This looks like a duplicate of https://github.com/hrydgard/ppsspp/issues/13201

At least the tremor in the menus.

Anyway that's just a workaround.

[ToniBC]

No, that doesn't work. The first and most important thing is that if we put 1 in frameskip we reduce the speed of the game to 50%, so that would not even have to exist as an option. xD

And yes, it reduces the shake, because instead of 30 fps it goes to 15 fps and it is less noticeable, but it never solves it in any case.

[kage2051]

Cannot reproduce the 'superimposed image' issue in Android version of RA (both 64-bit and 32-bit). Proof of that is shown in the screenshot below.

It seems it's affecting only Windows builds for some reason.

[unknownbrackets]

The game transfers a video to VRAM, and then later draws 0s over it iirc. If this isn't downloaded to VRAM, then you can get weird artifacts (which change if you skip the video at different points.)

If so, it would imply that block transfer or func replacments are not enabled.

-[Unknown]

[i30817]

You're not forgetting to add the ppsspp files the core needs to the right retroarch dir?

[ToniBC]

Add all assets from the last build to the ppsspp directory, otherwise it won't work.

And I tried changing options, but did not find any that would solve this. That is why it surprises me that when the core is updated, it fails only in retroarch and it seems that in Windows.

Then I try again, but it would be good for someone to also test it on Windows under Vulkan to see if it happens or not.

[ToniBC]

Tried the same game on Android, under Vulkan and without problems. Apparently the Windows version does not work well.

I have tried other games, and for example the 50 Cent: Bulletproof G Unit Edition also has shaking on the screen.

Others like Ace Combat X: Skies of Deception, Ace Combat: Joint Assault also do the same.

Curious.

[i30817]

This was fixed by

5313fc5b368b8d7c92d47b0560563ae613461188 is the first fixed commit commit 5313fc5b368b8d7c92d47b0560563ae613461188 Author: Henrik Rydgård hrydgard@gmail.com Date: Tue Aug 18 09:18:24 2020 +0200

More work on GL state leaks. Some things really need a redesign.

[ToniBC]

The shaking seems to be fixed, but the "dirt" on the screen is still present.

Tested on both GL and Vulkan on Windows.

The current version of libretro is d465ce5.

[i30817]

You're talking about the second screenshot right side in the original post you made? Because that doesn't happen here to me (possibly because of different graphics driver, or from using a retroarch with gles context instead of opengl however).

If you're talking about the fonts being blurred, i think that's on purpose. I think the shaking happened because a attempt at a blur effect was going on in the game itself and now it's 'fixed'.

Unknown mentioned it's possible that retroarch ppsspp is screwing up with function replacements somehow (i have them turned on but that doesn't mean much); so if a ancient function replacement removed the blur, i don't know if it is turned on. Someone should really debug that to make sure.

[ToniBC]

I mean marked, I tested it under Vulkan and GL in Windows 10 with the same result, Standalone version works fine.

It's like an image superimposed on that pattern, it's not that they move or anything, they're stuck there at all times.

Something is being misinterpreted in the Libretro version compared to the Standalone version.

In the Android version of Libretro, everything works fine under Vulkan or OpenGL.

[i30817]

This is it now running on a almost master retroarch built with gles and wayland only on a mesa driver for a very old rv710:

Could be a defect that only exists on some backends or some graphics cards. Or could be the antialising or increased internal resolution or filter you have, i notice you're much much smother and your color saturation is stronger.

[ToniBC]

This is with all the default settings. With native resolution, errors are less noticeable, but still present.

In this other, same team, with Vulkan driver and everything correct. PPSSPP v1.10.3-470. On Android under Retroarch it works fine too, it's only with Libretro and Windows from the looks of it. It would be nice if you verified the error other people, but in Windows, not in other systems, which is where the error is.

Different colors are also observed in Libretro, it may be that everything is derived from the same, that is, that everything is the same error.

[i30817]

I don't have or use windows. No confirmation from me, someone else will have to do it.

[kage2051]

I'm going to attach both results, top is from standalone app and bottom from RA core. Settings are: 1440x816, 2x xBRZ filtering, deposterize on, standalone running on Vulkan and RA core (64-bit) on GLES.

Standalone:

RA core:

As you can see, I cannot reproduce the issue on neither platform.

[ToniBC]

You are indicating that you tried it in the GLES version, but what I put is in the desktop version, with GPU Nvidia GTX 970 or higher, under Retroarch Windows x64 @kage2051

I'm not referring to the Android version, or Xbox, or that, the Windows version.

You say you can't reproduce the bug, but you're not testing the major version of Retroarch.

How difficult is it to test the version that most of us use?

Or is it that I do not understand which versions you are tested, because it is okay to test on other platforms, but do not skip the platform that fails.

[kage2051]

GL/Vulkan drivers on Windows tend to fail, especially on libretro cores. Have you tried using the Direct3D9/3D11 backend?

[hrydgard]

GL/Vulkan drivers on Windows tend to fail

Not really, they should work just as well as on any other platform.

[ToniBC]

It is as @hrydgard says, the problem is that something is wrong in Libretro, surely they will use a more updated version of the drivers on PC and it will fail because of that or because of some adaptation of them.

The other platforms, Android or GLES, have limited GL and Vulkan support for what they said and as PPSSPP is more adapted to that.

The problem is not the drivers as such, because the Standalone version on PC works without problems, it is the Libretro port that something did not adapt well in Windows and you will have to see what it is.

It would be nice if they fixed it because in Retroarch we can use shaders and bezels that will surely work better than in the Standalone version.

[kage2051]

GL/Vulkan drivers on Windows tend to fail

Not really, they should work just as well as on any other platform.

Well, I said that because it happens mostly on PCs with Intel integrated GPUs (especially if it's Sandy/Ivy Bridge/Haswell based). Since the OP uses an Nvidia GPU card, it might not be the case.

By the way, I've seen a few cases of people getting similar issues (on other emulators though, don't know if on PPSSPP too) due to them detecting the integrated GPU instead of the dedicated one.

[hrydgard]

That could be happening (detecting the wrong GPU) but it shouldn't cause these artifacts.

It might just be some weird issue in the libretro integration code in PPSSPP, or it can't access the asset files for some reason, or anything else. needs investigation, unfortunately higher priority would be actually getting Vulkan to work correctly with libretro again (it doesn't currently work, it looks like it does but it's because it switches to OpenGL). #13328 is the beginning of that work.

[i30817]

edit: never mind what was before this. I need to compile ppsspp with opengl 3.1 instead of GLES or fallback opengl (in libretro/LibretroGLContext.h).

[ghost]

I believe I am having the exact same problems with weird artifacts on screen just like @ToniBC. Using Retroarch win10 x64, with GL driver. On standlone PPSSPP, everything works and no artifacts are present. Tried multiple configs with same driver but nothing worked. Switching drivers to Vulkan or Dx9 just crashed PPSSPP.

[Ryunam]

Just chiming in to say that I am experiencing the same exact problem. The PPSSPP core with both gl and glcore video drivers will exhibit weird dots and visual artifacts on-screen with this game, which do not appear at all when using d3d9.

I am using an Nvidia GPU on a desktop PC (2700 Super) and I have disabled the integrated Intel GPU entirely from the BIOS/UEFI, so I don't think it's a GPU detection problem.

[ToniBC]

The problem has been fixed, now it looks the same as the Standalone version, so I close the issue.

Thank you very much.

[i30817]

Curious why, is it because of this https://github.com/libretro/RetroArch/pull/11490 RA commit? (which is only 10 hours old merged!)

If so it isn't so much 'fixed' as worked around with the core silently accepting whatever combination of RA driver / core driver it depended on in your machine (probably glcore/gles lol).

[ToniBC]

I can't tell you exactly, I use Vulkan as a driver, so I should use that when running PPSSPP, but of course, I may be using GLCore for some reason. But before it failed with all, the dirt on the screen was observed with all drivers.

I don't know when it was fixed, maybe it was something unrelated to PPSSPP or it was related to other things, like the screen shaking that was fixed before.