0.166 -> 0.5 local contrast threshold. Areas i shadows get no/less AA,
but in return, most texture detail is still there. High contrast edges
will still be processed.
Solves https://github.com/slashiee/cemu_graphic_packs/issues/422
Was requested over at the Cemu discord too after we took them away while we sanitized them, and there isn't really an issue with having these. Let's just keep those presets sanitized now.
Also found out that some random workaround had appeared in our resolutions folder 🤔.
Both were fully verified, so no issues should be present. This basically means that every game that runs properly (Star Wars doesn't go in-game, Tokyo Mirage is also very buggy and the upscaling filters don't work with cemu yet) before V5 will have graphic packs at least.
Didn't update the docs (will do that tomorrow), but I manually checked (didn't verify things, but I basically checked if it contained "uf_windowSpaceToClipSpaceTransform" and if the shader was made after a certain Cemu change was made due to how they're left out) to see if any graphic pack in here was *probably* safe.
I also didn't convert 5 graphic packs since they contained signs that needed to be manually checked or at least examined more:
- \Enhancements\TwilightPrincessHD_Bicubic
- \Resolutions\DevilsThird_Resolution
- \Resolutions\TwilightPrincessHD_Resolution (this one just needs to be fully verified since it's popular enough and has like 27 shaders)
- \Resolutions\LegoStarWars_Resolution
- \Resolutions\TokyoMirage_Resolution (this one could also be manually verified)
I hope I didn't make too many mistakes with this one.
I searched through quite a bit of commits to properly credit some packs. Some of the credits are based off memory. Please let me know if I incorrectly credited or forgot to credit somebody.
8x was overkill, and 4x is a tad unstable especially with 1.16.1 with texture allocation issues. Current pack settings will be reset back to 100% size due to preset naming changes.
Basically, the code previously would always replace the ratio calculation code for the 3d rendering and just load the upscaled width divided by the upscaled height. But the code gets passed other aspect ratios too, for example in the gear menu (and very likely other menus too).
So, even when users didn't use an ultrawide aspect ratio it would set the aspect ratio of anything that was 3d rendered to be 16:9, basically.
Comparison:
http://www.framecompare.com/image-compare/screenshotcomparison/D6WDWNNXhttps://cdn.discordapp.com/attachments/292733452590120961/663586520531337223/unknown.png
I made some assumptions about the other game versions regarding the floating point register that I use to load the scale float into, which is free to use in the EU 1.0.1 version at least.
I assume that the code for all of this is would be very similar though, since the previous ratio patch only had some addresses change across versions so it's probably fine.
This actually properly fixes https://github.com/slashiee/cemu_graphic_packs/issues/334 which was closed without any proper solution. Someone reported the issue in the Cemu Discord which made me fix it, since I thought the issue was addressed already.
Should fix the native anti-aliasing preset most importantly, but since I ported all of the packs now the script "watermark" is at least a proper sentence, heh.
Also, I fixed the porting scripts. Basically, there were a bug in the verification script that wouldn't check if the uf_* variables matched and the conversion script also had a fun bug where it wasn't automatically fixing an incorrect order of the uf_* variables. So that basically made both of them slip through. Both are now fixed however.
Don't know if it's needed to check the previously ported graphic packs to see if the error affected those, but it might not hurt.
3 unverified shaders, although one of them already had the Vulkan stuff in them. Can't find where the other two are.
280351fcf8e5949f_0000000000000000_vs
6d9067fd20086bc0_0000000000000000_vs
A wrong fps estimation can have visual artifacts among others. Even an estimation without visual artifacts will not be accurate emulation unless the fps was constant anyway.
Seems like something in the script isn't fixing the order of the glsl variables automatically, though the error ("This shader (with the current [preset name]) doesn't follow the uf_* variable order from Cemu itself, so it might've been messed with.") still got displayed.
Before I fix this problem with the script tomorrow (should be fine to continue to convert packs, just don't ignore the error thinking that it would be automatically fixed for now), I though that I would send this hotfix.
