Some games with quirky post-processing implementations can't have their resolutions properly upscaled

[I-Knight-I]

System Information rpcs3-v0.0.6-8464-0a5b6ad9

i9-9900K @ 4.70 GHz 16GB RAM GTX 980Ti Windows 10 Build 1803

I'll attach a log of LBP2 if required (Lemme know!). It may be several hundred MB's though.

Issue Games such as God Of War 3 and LittleBigPlanet 2 (only two I can test currently) can not have their resolutions upscaled without artefacting, blurriness or basically no improvement to resolution. It seems like only text and certain elements are upscaled making it only rarely sharper and clearer. Not sure of its reliability but this list shows what games do/don't have MLAA. Anyone able to test any of the others?

In the case of LBP2, performance is hugely negatively affected by having MLAA enabled. Disabling it by using a leaked debug build of the game results in a consistent 30FPS, better image quality and, if VSYNC is disabled, a consistent 60FPS. This is obviously because MLAA is processed on the CPU. In-game info shows CPU timings dropping 50% with MLAA disabled [See screenshots]. Ignore the game ID of LBP2. I made two installs and randomly gave it the ID BCES01080 in order to separate my real and debug installations.

God of War 3 (500% // 6400x3600) 500% to show effects easier

Sharper text and smoother edges on pause screen. Minor artefacting with mist/fog in background

LittleBigPlanet 2 [Debug] (200% // 2560x1440) MLAA enabled

MLAA disabled. Infinitely better image quality

Proof it's MLAA

CPU/GPU Timings

I mentioned this on the RPCS3 discord but thought I'd post it here too. At the time I was told that it could never be fixed and is reliant on game-specific patches. However, seeing its significant effects both on performance and image quality, I can't help but feel as though this needs its own issue and discussion to hopefully find a better solution. If fixed, games could have their resolutions upgraded to PC-tier quality and performance could improve by up to 25% or more (if LBP2 is anything to go off of).

[I-Knight-I]

Portal 2 is an interesting one. The image becomes sharper / less blurry but anti-aliasing seems to have completely gone out of the window. There's also a weird graphical effect where there are 'waves' on some textures - this is most easily seen on the back wall. Seems like this is the extent of the issue here. Interesting that edges become extremely jagged at such a high resolution though, maybe related to the MLAA reading the (upscaled) frame incorrectly?

Both images use an internal resolution of 1080p. Results were identical at 720p.

Portal 2

Portal 2 (500% // 6400x3600) 500% to show effects easier

1080p (100%) Zoomed

3600p (500%) Zoomed

[kd-11]

All these games will use different techniques for AA. Usually compute-heavy passes are offloaded to the SPUs (you can see how the work shifts away from the GPU when it is enabled) and we have to supply a downsampled image to fit the memory allocation. Outside of patching the binaries to remove the passes, I'm not seeing another solution for things like this.

[I-Knight-I]

Yeah, that was the general consensus from the discord too. As I say though, since it has such a significant impact on both graphical fidelity and performance, I felt I just had to make an issue. Hopefully someone can be creative or, in the future, think of a real solution.

I'm in no position to offer any sort of real advice but I am curious, so forgive my ignorance: could RPCS3 not even aid in or automate the creation of a patch? Maybe through memory editing similar to cheat engine? Perhaps even offer a config option that might disable AA instructions/calls on a per-game basis?

I'm not sure. I made this to ignite a discussion and hopefully lead to something is all.

[RainbowCookie32]

You may want to check out #6038 for that

[I-Knight-I]

Yeah, that's what I was thinking of. The only issue is it's not permanent I guess. I suppose future additions could allow for things like cheat tables and pointers etc but that'd be a decent amount of work, no?

[isJuhn]

RPCS3's patch system is enough, but you'd need someone to write the patch too. By the help of that lbp2 debug build it might not be so hard but in other games I can imagine this being quite the headache to get right.

[I-Knight-I]

Yeah, I've only an extremely basic understanding of assembler and memory editing but I can't imagine it'd be easy to find the value that controls things like this. With LBP2 it might not be so bad since there's clearly a toggle for it purely as a result of the debug build. If the internals of other games contain no such toggle, patches and memory editing will have to read/edit hundreds if not thousands of things, right?

[kd-11]

There is no such thing as AA instructions so this is the only way. RSX emulation is not really HLE'd by patching because the eboot has bits of the driver inlined into the code. In short, modifying operation of the EBOOT is the only way to get around this. Now, there has always been the option of doing shader replacement, but in these games that read back the values into CPU and then process the image there, this would have no effect.

[I-Knight-I]

That's unfortunate. I understand about other AA techniques but, just to clarify, isn't MLAA done completely by the CPU though? Not that I imagine it really changes much.

I'd like to request to the mods to keep this issue open for now though. Again, this is pretty significant so any other suggestions could be really useful.

[kd-11]

Yea, doesn't change much. From the POV of a processor (GPU or CPU) these effects are just basic arithmetic instruction sequences; we can't know its MLAA just like your physical CPU cannot know what you're actually doing on your desktop or in a game, etc.

[isJuhn]

Isn't this just patch.yml but a bit more user friendly? patch.yml is a file with first a hash which identifies the executable, and then it's just a series of hex edits: [type, offset, value]. rpcs3 decrypts and loads the executable into memory, then it applies all the hex edits from the patch file and then it launches the emulation. These patches are distributed on the rpcs3 github here and just through users on any medium.

There are of course improvements to be made on the user friendly side, like adding a UI for selecting which patches you want to enable etc. But right now it's good enough for something like this.

[I-Knight-I]

Correct me if I'm wrong but that's just memory editing and doesn't work for things like this. As kd-11 said, you'd need to manually edit the EBOOT files for changes like this. Of course, if you think you could get it to work using the current system, I'd love to know how!

[isJuhn]

it's for editing the executable without changing the file itself and it will work perfectly for stuff like this

[I-Knight-I]

Well, I'm intrigued now. You're certain this could work for all games, though? kd-11 seems to be pretty set on the fact this isn't gonna be solved without EBOOT edits.

[Whatcookie]

EBOOT.BIN is the executable. You can edit EBOOT.BIN with patch.yml

[I-Knight-I]

Hey Whatcookie, you're the one who responded to me on Discord originally. Hope you didn't interpret this post as me ignoring what you said, I just thought I'd see if there could be a greater discussion in a more centralised place.

But maybe I misinterpreted this then and realise now my suggestion is literally just patch.yml lol. I assumed that "EBOOT edits" meant manual hex editing using something like HxD and I assumed patch.yml was memory editing... or something. Again, excuse my ignorance and lack of knowledge.

Nonetheless, sucks that this is still patch.yml dependent. But knowing it's simpler than I originally thought is comforting, even if it's still slightly annoying though since it relies on people painstakingly creating this patches.

[kd-11]

If this is about a nice way of altering game logic then that is misguided and impossible. There is simply no way of altering the behavior of a game universally without changing either the bytes in the eboot (via hex edit or patch.yml which does the same thing but easier as it is a drag-drop solution) or changing the game's other files/assets via a mod. Either way, someone will have to painstakingly go through the bytestream and identify what needs changing. It will always be an intrusive process since you're literally going against what the developer of the program asked the program to do.

[ghost]

Sort of unrelated, but how did you manage to get the debug build of LBP2 to work? I want to use the debug menu to disable MLAA, but LBP2 kept on crashing whenever i tried to use the debug build.

[lextra2]

Didn't know FF13 uses MLAA on PS3. I thought it used MSAA. It for sure uses MSAA on PC since it only allows it to be set to a minimum of 2x in the options. And forcing it off via gpu driver menu shows you why: horrible eyelashes and brows since it relies on it for proper alpha transparency.

I guess I'll have to mess with cheat engine a lot to see if I can find the correct address to disable it.

[kd-11]

This ticket is not about MLAA per se, its about any game that uses CPU or 2D acceleration for post processing. I'll change the title to reflect this.

[lextra2]

This ticket is not about MLAA per se, its about any game that uses CPU or 2D acceleration for post processing. I'll change the title to reflect this.

alright. fair enough. Edit: I made a new ticket for FF13 as I do believe that MSAA does not work correctly for it.

[I-Knight-I]

@lextra2 In your new ticket you mention that disabling AA fixed the artifacting you were getting. I'm interested in why this doesn't work for the games I mentioned in this post though? Even with anti-aliasing off, the AA isn't actually disabled and I still get the same upscaling problems.

[I-Knight-I]

Feel compelled to mention #7211 here since it addresses the performance problems MLAA brought. Thanks to Whatcookie. Hopefully this'll lead to resolution upscaling in MLAA games in the future too!

[Darkhost1999]

Any update on this issue? Last comment appears to be 2 years old. Which games are still effected? Any changes?

[AniLeo]

You can now use FSR as a way to work around that

The other way is disabling MLAA through a game patch, which most if not all games that use it should already have

[MSuih]

There was some improvements that improved scaling compatibility, they were showcased in this video.

[nsoeth]

You can now use FSR as a way to work around that

The other way is disabling MLAA through a game patch, which most if not all games that use it should already have

Hmm, the problem exists i.e. in NHL 14 and NHL Legacy Edition. NHL 12 works fine. Anybody could help with this? I don't have a lot (none) experience with byte-editing.

[UnionExxis]

Sorry to necro this thread, but I think Captain America: Super Soldier might be one of these games that doesn't scale well. I am using 200% resolution scale to attempt to run the game at 1440p, there's some weird artifacts happening. Text in the UI seems upscaled as it is nice and sharp. Example here, look at edges of the helmet along his cheekbones and the fence in the background:

FSR certainly helps as an alterative, but even at 50% the image seems soft and text starts to take a hit

[Pacomatic1]

Just came to say that all the stuff in LBP2 also applies to LBP3; disabling MLAA improves performance and upscaling and all that. Sadly, using the patch provided to disable MLAA on LBP3 also disables other effects.