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
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.
Detected some faulty presets with my script, since logging these kind of issues make sense. Doing these separately since otherwise the big commit will make these changes invisible.
Since it's not possible to update 300+ shaders manually and automation was possible, I thought that I'd take the honor and create a script that's able to automatically convert all of the shaders to be cross-compatible with Vulkan. And change the graphic pack versions to version 4 of course.
Also, the script has some nifty testing code which compiled every shader as OpenGL and Vulkan, but for that see the details that I've written below.
**Here's the script that I've made to do all of this. No manual edits were needed:**
https://gist.github.com/Crementif/8d98a855b95f219d95298fb3db99deae
Since I wanted to make sure that I didn't broke the shaders after converting the shaders to Vulkan, we need to check if all the shaders weren't broken. Since we're talking about like 400 shaders checking all of them is pretty much impossible and even then,
So, the obvious solution was to automate the checking. Not as simple as you'd think, because in 300 of our shaders we use preset variables which without replacing the value like Cemu does, will make the shader error regardless. So I also implemented some functionality that would read the preset values and types out of the rules.txt file and replace them in the shaders using that information. And then we use Khronos' glslang to compile the shaders, using both OpenGL and Vulkan.
The result was that glslang found quite a few errors in some of the shaders, which I fixed in this commit. I'm considering adding this rules.txt parsing and automated shader compilation testing to the build process.
Also, I fixed Clarity's name and description since Monochromia isn't available anymore and Xenoblade's resolution pack had a lot of weird blank lines before their #version declaration, which my converter didn't like.
With Cemu 1.15.12 's gl_PointCoord support, night stars now have proper (varying) alpha value. Should be no need for workaround anymore, just scale its size accordingly.
Add: Scaling of world map
Add : 16:10 resolutions
Add : x2 SSAA vert res for 21:9, 48x9
Fix : Better alpha for x2 Subres, rounds to native x2 if possible
The game re-applies a cropped 1280x400 background in order to create the fading on the inventory borders. Not resizing it causes the background especially Link and items he is holding to become blurry and aliased mid-screen with two cutoff lines. This rule was present in pre-1.14 rules.
