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.
Xenoblade Chronicles X packs are now ported too! Which has, after BotW, the most shaders I think made by all of the efforts from getdls. All shaders were successfully verified and tested in-game (from what I could tell).
But now done properly! Basically, a bunch of improvements were made to the script. The previous attempt at this conversion was quickly followed by a rollback since I realized that the script was overlooking certain things that made most of the packs hit or miss whether they would work. A few things missing were:
- It only tested the values from 1 preset. Now, each shader gets compiled per each preset, like what Cemu would do. It also merges the changes done for each preset into one. This should solve cases where one shader would define things separately or repeatedly from preset to preset.
- All* of the shaders are tested to see if they use the converter used the right values for the locations for Vulkan.
Both of these *should* mean that they should both compile and be linkable in Vulkan, which means that I don't have to test each individual shader to see if they work. I will release the two scripts (one used for converting, one used for checking the right values for the locations) tomorrow so that other people might be able to help, if they want. It's fairly straightforward now at least.
* Organize workaround graphic packs
Pretty hard to organize these correctly, but according to our discord discussion, this was the best layout from a bunch I proposed, together with some suggestions.
* Add V4 converter script and instructions on how to use it
Now everyone BotW is done and all of the bugs have been kinked out using it (hopefully...), here's the release of the converter script in all of it's very badly coded glory. I hope I didn't leave too much debug glory in there...
Also, I hope that I didn't make too many grammatical mistakes in the instructions, but hopefully it's easy enough to follow.
* Update rules.txt
add "(OpenGL)" to title and rendererFilter to this pack since it creates crashes on vulkan and is not nessecary due enforcement of GX2DrawDone on vulkan
* Update rules.txt
