Custom Texture Tool PS v50.1

Techie Android · 10-11-2017, 07:49 AM **#421**

I get this when I enable the double click to open PowerShell option.

Code:

Program 'regedit.exe' failed to run: Unknown error (0xc0000005)At C:\Users\youbr\Downloads\Custom Texture Tool PS

v27.0\Custom Texture Tool PS v27.0.ps1:10378 char:3

+   regedit /s $TempRegFile

+   ~~~~~~~~~~~~~~~~~~~~~~~.

At C:\Users\youbr\Downloads\Custom Texture Tool PS v27.0\Custom Texture Tool PS v27.0.ps1:10378 char:3

+   regedit /s $TempRegFile

+   ~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException

    + FullyQualifiedErrorId : NativeCommandFailed

**Bighead** · 10-11-2017, 10:27 AM **#422**

(10-11-2017, 07:21 AM)Techie Android Wrote: @Bighead
What are the main differences in uncompressed DDS BC7 and compressed DDS BC7 (like the size and performance differences)?

BC7 is a lossy compression algorithm, so uncompressed BC7 does not exist. ARGB32 is uncompressed and lossless, and requires 4x the VRAM/disk space as BC7. Performance for uncompressed DDS should be faster than PNG (in most cases) because they do not need to be decoded, the image quality is equal, and both consume the same amount of VRAM. Uncompressed DDS are much larger than PNG in file size because PNG files are losslessly compressed. Because uncompressed DDS textures are 4x the size of DXT3/DXT5/BC7 (and 8x the size of DXT1), there will be increased latency when loading them, so they are not ideal for complex scenes (such as environments) as it may introduce stutter that is not present in compressed textures. Depending on the size of the textures, and performance of the hard drive, it may even be worse than PNG if not prefetched.

The ideal use for uncompressed DDS is for UI textures and fonts where transparency meets color. These textures are usually not very big (in both resolution and file size), and are much more sensitive to drops in quality. I suppose they would also be useful for sprite heavy games (like Paper Mario) although BC7 does a fine job already. Using them for all textures in a pack is not very practical unless the pack does not contain many textures, or contains very small textures.

Let me give an example:
• The Xenoblade pack, using only BC7 textures will consume a little over 2GB of VRAM. This is the best performance, but BC7 can have artifacts around transparent edges (refer to my Shulk example). The quality is almost PNG, and the requirements are light, but the videophile will be unhappy if they notice these artifacts.
• Using only PNG or uncompressed DDS, the pack will consume over 8GB of VRAM and be far more stuttery, with very little (maybe even indistinguishable) improvement to visual quality. If using only uncompressed DDS, the pack will be 4x the size on disk compared to using just BC7 textures.
• Using a mix of uncompressed DDS textures for the UI textures and sprites, and BC7 for the environments and skins (basically opaque textures), the pack will consume 3.4GB of VRAM (or prefetched RAM). This keeps the requirements lower while offering higher quality for the textures that matter. So the pack creator must be selective when choosing which textures to create as ARGB32. This is why I introduced the "User Defined" option to convert textures using flags that can be put on texture pack folders.

Knowing your packs VRAM requirement is useful, which is why I added the option to calculate how much VRAM it will consume without having to load it into Dolphin. Just looking at the file sizes can give a very close estimate of the requirement, but the 128/148 byte DDS headers are not part of the equation (at least to my knowledge). All in all, it will require some knowledge and common sense to properly create packs using a mix of different types of DDS formats. To keep it simple, the only two that really matter, at least when it comes to quality and performance, are BC7 and ARGB32.

(10-11-2017, 07:49 AM)Techie Android Wrote: I get this when I enable the double click to open PowerShell option.

Code:

Program 'regedit.exe' failed to run: Unknown error (0xc0000005)At C:\Users\youbr\Downloads\Custom Texture Tool PS v27.0\Custom Texture Tool PS v27.0.ps1:10378 char:3 + regedit /s $TempRegFile + ~~~~~~~~~~~~~~~~~~~~~~~. At C:\Users\youbr\Downloads\Custom Texture Tool PS v27.0\Custom Texture Tool PS v27.0.ps1:10378 char:3 + regedit /s $TempRegFile + ~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException + FullyQualifiedErrorId : NativeCommandFailed

I'm not sure what would cause this issue, but it may be related to whatever was causing the corrupt textures. From my very brief research, it seems the 0xC0000005 error means the program was trying to access RAM that it shouldn't. In some reported cases, this ended up being a bad stick. But since this is happening in a VM, it could very well be an issue with that rather than the RAM itself.

Maybe try running "regedit" from the "Run" app (just do a search for Run) just to see if it is indeed not working correctly. If it works and you want to apply the hack yourself, navigate to "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Microsoft.PowerShellScript.1\Shell". To the right, change the (Default) value from "Open" to "0".

**Bighead** · (This post was last modified: 03-28-2020, 02:36 PM by Bighead.)

DDS Format Flags

The purpose of these flags is to be able to generate a pack using multiple types of DDS formats in a single run when selecting *Search Flags* as the DDS Format. Flags can be added to a folder name or texture name. When added to a folder, all textures in that folder and all sub-folders will be created with that type of compression.

Format Flags List: (Show Spoiler)

Automatic Flag Removal: (Show Spoiler)

I'm Not Reading All This (so Teach Me QUICK!): (Show Spoiler)

Reference Pack For Below Examples: (Show Spoiler)

Utilizing Compression Flags: (Show Spoiler)

Multiple Compression Types - Complex Methods: (Show Spoiler)

By knowing the order that the script searches for the flags, we can get away with using a second flag to convert specific textures to a different format than the first flag.
This is the full search order: BCX > BC1 > BC2 > BC3 > BC4 > BC5 > BC6 > BC7 > ARGB8 > RGBA8 > L8 > A8 > LA8

Since BC7 is before ARGB8, this means that BC7 will always be used over ARGB8. So what if SubFolderA1 contains a single texture we want to convert to BC7? Simple, we can add the BC7 flag directly to the texture name.

The full path to the texture should look like: TexturePack/_ARGB8/FolderA/SubFolderA1/sometexA_BC7.png. This single texture will be created with BC7, while all other textures in that same folder will be created as ARGB8.

Now let's take a look at SubFolderC1A which contains a texture named sometexB.png that we want to convert to ARGB8. The path to this texture contains no flags, so it will be using the DDS Fallback setting of BC7. But we want ARGB8 for this texture, so we can just add the flag to the texure name. Even though ARGB8 is near the bottom of the search list, it only competes with other flags and not the fallback. The result is this texture is created as ARGB8, and every other texture in this folder is created with BC7.

Again, even with this mess of a flag naming scheme, after everything is finished the hierarchy and names will be restored to the original structure.

Code:

TexturePack / _ARGB8  / FolderA     / SubFolderA1  / sometexA_BC7.png

                                    / SubFolderA2

                      / FolderB     / SubFolderB1

                                    / SubFolderB2

            / FolderC / SubFolderC1 / SubFolderC1A / sometexB_ARGB8.png

                                    / SubFolderC1B

                      / SubFolderC2

            / FolderD

And for the sake of a second example showing it another way to obtain the same effect.

Code:

TexturePack / FolderA_ARGB8 / SubFolderA1 / sometexA_BC7.png

                            / SubFolderA2

            / FolderB_ARGB8 / SubFolderB1

                            / SubFolderB2

            / FolderC       / SubFolderC1 / SubFolderC1A / sometexB_ARGB8.png

                                          / SubFolderC1B

                            / SubFolderC2

            / FolderD

Mistakes To Avoid: (Show Spoiler)

Advanced Flag Usage: (Show Spoiler)

This crazy example assumes we want an oldskool legacy DDS pack using the D3D9 DXTC compression types (meaning DDS Fallback is set to BC1/BC3) as well as uncompressed ARGB8 for UI textures and the like.

At this point we should be able to see what everything will be created with and why. An important thing to notice is texture sometexA.png. If opaque, it will be created with BC1/DXT1 compression as BCX is first in the list.

There is a mistake below and something will not be converted with the intended result, can you spot it?

Code:

TexturePack / FolderA_ARGB8 / SubFolderA1_BC3 / sometexA_BCX.png

                            / SubFolderA2

            / FolderB_BC3   / SubFolderB1

                            / SubFolderB2_BCX / sometexB_ARGB8.png

            / FolderC_ARGB8 / SubFolderC1     / SubFolderC1A / sometexB_BCX.png

                                              / SubFolderC1B

                            / SubFolderC2_BC3 / sometexC_BCX.png

            / FolderD_ARGB8

Answer: (Show Spoiler)

In conclusion the idea behind all this is simple enough, but it can be tricky getting the desired result depending on the pack's folder structure. This was the best idea I could come up with to automate the creation of a DDS pack with multiple formats. My hopes is it will also help others create the best possible quality DDS packs. I tested it quite heavily, but knowing my own history there's probably some well hidden bugs.

Techie Android · 10-12-2017, 11:52 PM **#424**

Oh okay. I wasn't sure what you meant when you said uncompressed DDS and then said there wasn't such a thing. I must have misread when you were talking about BC7.

So ARGB32 is the only option that is a lossless uncompressed DDS format.

**Bighead** · 10-13-2017, 08:05 AM **#425**

It's the only uncompressed option my script provides as it should fit all our needs, and it's the only one that I can tell that Dolphin supports. If you're interested, this is the list of D3D9 formats, the list of D3D10/11 formats, and the analogues between them.

themanuel · 10-16-2017, 02:07 AM **#426**

Hi, Bighead. I have a question about scaling and conversions.

Because I use a small SSD hard drive for my OS and also keep the dolphin user folder there, I usually downscale big texture pack releases to 4x. This has worked great for me and I do not see an appreciable difference in my 1080p displays. For example, I have downscaled both, the Super Mario Sunshine (razius') and Wind Waker packs and they look great to me, while reduced in size to about a fourth or so of the original. If I closely compare the originals with the downscaled ones there is a small difference in quality but hardly noticeable during normal gameplay.

However, I have been having trouble downscaling the SM64 pack [url=Hi, Bighead. I have a question about scaling and conversions. Because I use a small SSD hard drive for my OS and also kee the dolhin user folder there, I usually downscale big texture ack releases to 4x. This has worked great for me and I do not see an areciable difference in my 1080 dislays. For examle, I have downscaled both, the Suer Mario Sunshine (razius') and Wind Waker acks and they look great to me. If I closely comare the originals with the downscaled ones there is a small difference in quality but hardly noticeable during normal gamelay. However, I have been having trouble downscaling the SM64 ack here.]here[/url] (admentus). For some reason, when I downscale it, the loss of visual quality is quite obvious. I realize that the pack is not that big to begin with, so this is more a question about the use of the tool and the nature of the pack, for my learning. I can simply use it as is but I'm just curious.

I have tried the following conversions:

4x DDS DXT1/5 with ImageMagick
4x DDS BC7 with ImageMagick
4x DDS BC7 with TextConv

All of these produce the same obvious reduction in quality and the pack shrinks to about a tenth of the original size, which is more than I was expecting.

Do you think this may be due to something related to this pack, specifically or am I doing something wrong?

PS: I've been working under the impression that selecting a 4x scaling doesn't reduce the scale by a factor 4 necessarily, but rather scales it down to 4x from whatever scale it original was relative to the source texture in the original game.

**Bighead** · 10-18-2017, 10:07 PM **#427**

(10-16-2017, 02:07 AM)hemanuel Wrote: PS: I've been working under the impression that selecting a 4x scaling doesn't reduce the scale by a factor 4 necessarily, but rather scales it down to 4x from whatever scale it original was relative to the source texture in the original game.

Somehow I missed this post, sorry for the late response. You are correct about this, dimensions are calculated from the original resolution * the scaling factor, and the custom texture resolution is ignored. I do it this way so the resulting dimensions always end up with an even integer upscale. For example, tex1_32x32_55ea7d492516c989_5 with a rescale factor of 4x would result in a 128x128 texture. A lot of the textures in that pack that were originally 32x32, are retextured as 1024x1024, which is a 32x increase. So it's no surprise that you see a huge drop in quality when comparing 4x vs. 32x.

Since N64 textures are on average much smaller than gamecube and wii textures, you may want a higher rescale factor. Going up to 6x may be the improvement you want, but even 8-12x might be worth a shot if the results are still looking bad. If you want to prevent accidentally upscaling any textures, you can set the Rescale Condition to Downscale. This way if you set something like 8-12x, and a 4x scaled retexture is found, it will not be rescaled. Also, BC7 should always be used over DXTn if your GPU supports DX11+, as it is higher quality than DXT5 and RAM consumption is equal between the two.

(10-16-2017, 02:07 AM)hemanuel Wrote: I have tried the following conversions:

4x DDS DXT1/5 with ImageMagick

4x DDS BC7 with ImageMagick

4x DDS BC7 with TextConv

Just an FYI, the only programs compatible with this script that can create BC7 are Compressonator and TexConv. The selected DDS program is more of a preference than a choice, as it will always select the one it needs if the selected program can't handle the output. In the case of selecting "ImageMagick" for creating BC7, it silently falls back to Compressonator or TexConv.

themanuel · 10-18-2017, 11:35 PM **#428**

Thanks, Bighead. Very helpful.

I'll rescale to a higher factor (downscale only). I'll also download compressonator as it seems like that would be the best, per your first post.

One more:
When I rescale DDS packs, do I lose anything by choosing BC7 as the output, even if the original pack used DXTn?

**Bighead** · 10-19-2017, 11:38 AM **#429**

There is always at least some loss when using lossy formats, especially one lossy format to another. Going from DXTn formats to BC7 the loss is probably minimal, but there will certainly be no gains when doing this.

themanuel · 10-19-2017, 11:47 AM **#430**

(10-19-2017, 11:38 AM)Bighead Wrote: There is always at least some loss when using lossy formats, especially one lossy format to another. Going from DXTn formats to BC7 the loss is probably minimal, but there will certainly be no gains when doing this.

Would it be better in those cases then to downscale using DXTn if that was the original format or will there be a loss anyway because the textures need to be decompressed, rescaled and then compressed again?