Custom Texture Tool PS v50.1

Aggro_hamtaro · 01-06-2021, 09:06 PM **#1,031**

Can this app transform resource packs into texture packs and be used to change DDS texture packs into PNG packs? I am on android and the DDS format isn't supported by my phone's graphic drivers.

**Bighead** · 01-07-2021, 01:10 AM **#1,032**

Yes this tool can convert DDS to PNG. As for resource packs, you don't need to convert anything. Just extract the zip file, find the "textures" folder, inside should be a folder named to the game ID. That is the texture pack that can be dropped into the load\textures folder.

Aggro_hamtaro · 01-07-2021, 10:10 AM **#1,033**

Thanks a lot!

BlueSwordM

@Bighead, I can confirm.
The issue has been fixed, on Linux anyway.

Also, compiler optimizations on CPUs massively speed up the execution speeds of Compressonator.

I'm going from 55 seconds on a 2000x2000 image to 10 seconds on a 3700X

**Bighead** · (This post was last modified: 08-13-2021, 02:20 PM by Bighead.)

WHY IS THIS STILL A "BETA" VERSION? IT'S BEEN OVER A YEAR!

I planned on making v47.0 "official" when Compressonator released with the fixes I need (here, here) so I can update the script accordingly. But it is taking them a long time to get the next update out with those fixes. Besides, it's just a number. Consider this "beta" line my official releases for now. Despite the many versions I put out, I never put them out knowing there is bugs, and right now I can't help but release it with a known bug.

Note: Beta versions are officially done. The release is now out.

Release Version:
https://www.mediafire.com/file/6x9srnrththpoo6/Custom_Texture_Tool_PS_v47.0.7z/file

Previous Betas: (Show Spoiler)

This completely changes the way high DPI mode works so it scales infinitely and no longer requires external modules. The script will automatically remove the "DPI" folder from the CTT-PS global folder for anyone who tested the last beta version. Because I have been working on this on and off for months now (with it being a long term goal for years), and pretty much put everything else on hold, I thought it might be worth it to chronicle my journey of creating a PowerShell GUI that scales with DPI. Here I explain how I accomplished it as there may eventually be someone else out there who will face the same struggle and will hopefully come across this post.

Now I'm the farthest thing from an expert when it comes to making a GUI using PowerShell and winforms (or really, coding in general), and there may even be a one line fix that I just couldn't find. If there is, then... Confused

But with how quirky winforms is, if it was possible to make a PowerShell-written winforms GUI DPI aware, I'm sure it would still require a bunch of tweaking. As far as I can tell, the method used here works well. If anyone else also follows the progress of the Patcher64+ Tool by Admentus, then you probably already may have guessed it was coming to this script as well.

The Scaling Bug-inning

The idea of implementing high DPI support goes all the way back to 2017 when a user discovered the script was broken with high DPI:
https://forums.dolphin-emu.org/Thread-custom-texture-tool-ps-v46-2?pid=436023#pid436023

What... what's going on here?

And this was my assessment/solution of the "bug":
https://forums.dolphin-emu.org/Thread-custom-texture-tool-ps-v46-2?pid=436034#pid436034

In short, it turns out the script must have been reporting that there was some kind of high DPI shenanigans going on, as Windows was not auto-scaling the window with an upscaling filter like it normally does. But, it was scaling the text. I thought what a strange bug this is and had zero clue as to what was going on. Initially, I tried to scale the dialog manually. I guess I could say that this was my first attempt at creating a high DPI GUI. I manged to make it look nice at 100% scaling and 125%, albeit far from perfect. Beyond that though... still broken. This just wasn't going to work.

After uploading my generic (sorta) fix, I dug around a bit more and finally figured out that the culprit was a bitmap function I was using from the "PresentationFramework" assembly, which is part of Windows Presentation Foundation (WPF). I was using a function that I found online to create an icon for the GUI from a bitmap image, which was created from a base 64 string. I was a total noob and had no idea how it worked at the time, I was just happy that it did. Being able to convert images to a base 64 string and storing the string directly in the script is a nice and easy way to have the images "built-into" the code. Anyway, this part of the story will have great significance later.

Eyeglasses Don't Work

So fast forward 3 years. I've since upgraded to a 1440p 144Hz IPS monitor, and the blurriness of the GUI was immediately apparent to me. It felt like I had to squint or something when looking at it, and really made the tool I spent all these years working on feel "outdated". Over the years, I did occasionally research on how to make CTT-PS DPI aware, but my searches always ended up with me leaving even more confused than before. It seemed simple enough in theory to make an application "DPI-Aware" when writing a C# program, but not when making a PowerShell script. I still have never found an answer, and I don't even know what the DPI-Aware flag even does. I had to be missing something simple, right? I decided to turn to the pros for help.
https://stackoverflow.com/questions/63907191/powershell-dpi-aware-form

Unfortunately, I didn't really get a good answer (or really, any answer). I thought if I could at least get Windows to stop scaling the window with that blurry filter, then I could build a custom GUI at each DPI setting. Then came the epiphany: I remembered a few years ago someone had an issue because exactly that was happening. The answer must lie within Windows Presentation Foundation (WPF)! Now I really don't know anything about it or what it does (and still don't), but I do know that it somehow disabled auto-scaling. So, I dug up my old version of the script with the "bug", copied the code to create an icon, and boom! The GUI was not scaling, but it was also very broken again. But that didn't matter as this time it is exactly what I wanted.

The magic code that disabled automatic scaling...

Disable Auto-Scaling: The Solution

While this worked, it was bulky (plus I omitted a few lines) and I didn't like that I essentially had to create a dummy bitmap and a base 64 string just to disable scaling. So I started to look at other WPF code examples that were using presentation framework, and noticed some simple code to create a "Window" with XAML. I stripped it down to the barest possible code to create a "dummy" window that had no properties and was never actually shown. Gave it a whirl and success, no scaling: so I made it into a function I could call on initialization.

This does the trick, and it's nice and neat in my opinion.

I liked this much more than the bitmap trick only for the reason it was simpler, cleaner I guess? But both did essentially the same thing.

It's Decent Enough, But...

So now that I could disable scaling, it was time to create my DPI database files. Initially, I just manually cloned the upscaled version of the GUI by setting new values for everything on the non-scaled version. This took a very long time as I did it for 6 different DPI settings. I was pretty happy with the results, as I was able to completely control how the dialog looked at every DPI as long as a database existed for it. This implementation is what is used in the last beta I uploaded.

These were an absolute nightmare to create and ended up being a waste of time.

It wasn't long after that I quickly realized what a pain it would be to add any new features as it would be 7 code bases to maintain, and each would have to be tested under their respective DPI! I had to think of a better solution...

DPI Scaling: The Multiplier

Brainstorming time again. Time to figure out some math to scale everything through calculation and not static values. So....

96 DPI, 100% scaling
120 DPI, 125% scaling
144 DPI, 150% scaling

96 DPI is 100% size. Each step up is 24 DPI. Each step up is 25% larger. Think Bighead...
The DPI is known, but somehow needs to be used to scale a value by a percentage...
A lookup table could work, so could a loop, but there has to be a better way to correlate the two...
So what we need, is to somehow get the amount of change as a percentage of the current DPI in one simple formula!

You could say this simple little equation was the culmination of months of work...

So far so good. Looking at it, it's so simple and obvious that I can't believe it took me this long to come up with it. 96 DPI ends up with 1.00 multiplier, 120 DPI with 1.25 multiplier, 144 with 1.50 multiplier, and so on. Now that I know that automatic scaling can be disabled, and a database file proved that a high DPI GUI can exist, I started to wonder.. can it be automated? Or rather, can I calculate all the required values instead of building and pulling them from a database? Well, I was about to find out. I was highly skeptical at first, what I had worked, so I kept a backup of the script close by just in case this idea went to shit.

DPI Scaling: The Function

Having the DPI multiplier is useful, but not very useful by itself. I needed to write a function that could multiply a value by the DPI multiplier. There are many places I use integers that need scaled, and there are two types of objects I use that store a pair of integers: [Drawing.Size] and [Drawing.Point]. Size is referenced with (width/height) while Point is referenced with (X/Y). All of these values would need to be updated with the (soon to be written) multiplier function. I knew this would be a lot of effort as there are 1000s of values in CTT-PS, but the end would be worth it if it worked.

This is where the magic happens.

I settled on the name "DPISize" because it's short and easy to type/remember. The function itself is a little unsightly, and there is more going on that I will cover later. In its current form, it handles just about any type of number or pair numbers I can throw at it, and it will return the scaled value(s). Now it just needs to replace a couple thousand raw values.

Now We're Getting... Somewhere

So now I have something short and easy to use that needs to be plopped in everwhere there is a raw value. Calling it is simple enough, where I would enter a value, lets say (100) I would instead use (DPISize 100).

96 DPI: 100 * 1.00 = 100
120 DPI: 100 * 1.25 = 125
144 DPI: 100 * 1.50 = 150

It's as simple as "DPISize <value>" to calculate the value based on current DPI.

Theoretically, the GUI should scale up by a near perfect 25% with each DPI increase, and this works pretty well for about 95% of values. I did start to notice some inconsistencies though as the "size" of some objects are not always equal. TextBox height is controlled by font size. GroupBox has some space before the border that is not a perfect 25% larger. I also have no idea how PowerShell does automatic rounding when hard casting a value to an integer, but it makes no sense to me. For example, 10.5 rounds to 10, and 11.5 rounds to 12. This goes against what I understand, so I decided to just truncate the decimal completely under normal operation. I wanted the ability to round as well, so I added a -Round switch to force rounding, as some things seem to like this better when lining stuff up.

Need More Control!

So being able to control when the value is rounded or not definitely helps, but it's still not good enough. There are a few bad eggs that did not want to behave: TextBoxes, ComboBoxes, and NumericUpDowns. With each increasing DPI, they drift further and further away from being vertically centered. This is due to the fact they vertically scale to the font, the size entered for height is ignored, and fonts do not scale linearly with the GUI.

TextBox is vertically offset although everything is scaled the same.

The Offset Fix

Now I could have just set some magic numbers to fix this problem. But I wanted it to be calculated so it will scale infinitely. The first step was to find a pattern, so I started jotting numbers down hoping something sticks out...

Ok, so what am I looking at here? At each increasing DPI, the object drifts further away by about 1 pixel. The multiplier is the key somehow. How can it be used to obtain the pixels needed? Directly, it can't. But subtracting 1 from the value gives us the amount of increase from 100%. For example, 120 DPI is 25% larger than 96 DPI, so to get that, subtract 1 from 1.25 gives us 0.25. Now let's divide that by the 1 pixel needed. The result: 4

And we found our pattern, now we have our formula:
144 DPI is 150%, 1.50 multiplier - 1.00 adjust = 0.50 percent, 2 pixels / 0.5 = 4
168 DPI is 175%, 1.75 multiplier - 1.00 adjust = 0.75 percent, 3 pixels / 0.75 = 4
192 DPI is 200%, 2.00 multiplier - 1.00 adjust = 1.00 percent, 4 pixels / 1.00 = 4

Should have been obvious but my gears turn a little bit slow.

-Add, -AddX, and -AddY

If you look back at the DPISize function, there are a few paramters I didn't explain: -Add, -AddX, and -AddY. Simple concept, these are added to the final value(s) to nudge the object. For a single integer, all three function identically and can be used as 3 different additions. For a pair of numbers (Size/Point), -AddX and -AddY add to their respective axis, while the -Add parameter will add to both numbers.

This is a very simple way to add this offset fix to all TextBox, ComboBox, and NumericUpDown. The result isn't perfect in every DPI, but it's extremely close.

Overall, the function should hopefully be powerful enough at this point to line everything up.

Sunset Road

Story is over, now go away! So yeah that was a doozy. It took a while to type all this up but it in retrospect, it was merely a fraction of the time I embarassingly spent on this DPI stuff. As a test I have also implemented this method into the Patcher64+ Tool by Admentus, and it worked pretty well there without much effort (it will be up to him to fix the remaining issues hehe). While the GUI is pretty much close to perfect in the latest CTT-PS beta, there is still room for improvement. CTT-PS was designed entirely using absolute positions. Making some objects relative to others would increase the accuracy at which some things line up. But for now, I need a small break. I'll be happy to finally put this to rest and start working on something.. that isn't this.

01-28-2021, 09:00 AM **#1,036**

Can anyone help me? and tell me if this could work for me? Huh

I was trying to translate Trails of cold steel 2 to spanish on PC, i've found this thread and it seems that it may work.

I converted the text from .tbl files to .xml files and it can convert them again to .tbl using a python program.

The thing is this game has a lot of .pkg files with textures and pictures that i would have to edit and compress them again.

But it seems a lot of work, and i dont even know if that will work, will this work for me? or the pc version files are different?

Woah. I installed a lot of crap that i didn't need, i Just had to follow the instalation steps... but now i cant convert .pkg to pictures it says that i need netcore, tried to install it it said ok at first, but won't work. tried to reinstall it , it says something abour iis not being enabled Sad

i can't make it work Sad

Edit n°3: i tried everything, installed even visual studio tried to compile that tool but my knowledge is too low.

The problem is when i try to unpack or repack.

I used the other tool to unpack the .pkg, then i could extract png from .phyre with ctt (but they are so small, i don't know it this is supposed to be like this) , tried to Repack with CTT, but no luck.

I used the same tool (PKGTool) to repack but the size went from 400kb to 2.6 mb....

pls help?

**Bighead** · (This post was last modified: 01-28-2021, 11:27 PM by Bighead.)

(01-28-2021, 09:00 AM)oxidonitroso88 Wrote: Can anyone help me? and tell me if this could work for me?

I was trying to translate Trails of cold steel 2 to spanish on PC, i've found this thread and it seems that it may work.

I converted the text from .tbl files to .xml files and it can convert them again to .tbl using a python program.

This forum is for Dolphin emulator texture packs, so I'm probably one of the few here who can give any advice. My texture tool is probably the only tool that can actually work directly with phyre textures, and this is the only place I posted it. So I will at least discuss the texture aspects of your questions, but translating the language part of the game is outside of the scope of this thread and this tool. But it seems you already got a handle on it anyway.

(01-28-2021, 09:00 AM)oxidonitroso88 Wrote: The thing is this game has a lot of .pkg files with textures and pictures that i would have to edit and compress them again.

But it seems a lot of work, and i dont even know if that will work, will this work for me? or the pc version files are different?

Woah. I installed a lot of crap that i didn't need, i Just had to follow the instalation steps... but now i cant convert .pkg to pictures it says that i need netcore, tried to install it it said ok at first, but won't work. tried to reinstall it , it says something abour iis not being enabled

You need a specific version of .NET Core to use Sewer56's PKG tool, anything v2.x should work, anything v1.x or v3.x will not work. You can get v2.1 (which is still supported), or v2.0/v2.2 here:
https://dotnet.microsoft.com/download/dotnet-core

(01-28-2021, 09:00 AM)oxidonitroso88 Wrote: Edit n°3: i tried everything, installed even visual studio tried to compile that tool but my knowledge is too low.

The problem is when i try to unpack or repack.

I used the other tool to unpack the .pkg, then i could extract png from .phyre with ctt (but they are so small, i don't know it this is supposed to be like this) , tried to Repack with CTT, but no luck.

I used the same tool (PKGTool) to repack but the size went from 400kb to 2.6 mb....

PKG files are compressed. Sewer56's PKG tool is the only one that supports (re)compression. Using the PKGTool by thesupersonic16, the PKG files are going to be much larger after they are repacked. When you get the proper .NET Core installed, to use Sewer56's tool it should be as simple as linking CTT-PS to "PKGToolCmd.dll". If all else fails, you can also link PKGTool to this script. It will create larger uncompressed PKG files, but they will work the same.

If you haven't seen this post I do suggest checking it out:
https://forums.dolphin-emu.org/Thread-custom-texture-tool-ps-v46-2?pid=482262#pid482262

Aside from all that, you do have your work cut out for you if you intend to translate all the textures. Some textures use alphanumeric characters from a "grid" to spell things out, so I have no idea how they could be translated. For example...

Spoiler: (Show Spoiler)

I have no idea what you could do for that texture and a few others like it.

01-29-2021, 01:38 AM **#1,038**

(01-28-2021, 11:23 PM)Bighead Wrote: This forum is for Dolphin emulator texture packs, so I'm probably one of the few here who can give any advice. My texture tool is probably the only tool that can actually work directly with phyre textures, and this is the only place I posted it. So I will at least discuss the texture aspects of your questions, but translating the language part of the game is outside of the scope of this thread and this tool. But it seems you already got a handle on it anyway.

You need a specific version of .NET Core to use Sewer56's PKG tool, anything v2.x should work, anything v1.x or v3.x will not work. You can get v2.1 (which is still supported), or v2.0/v2.2 here:
https://dotnet.microsoft.com/download/dotnet-core

PKG files are compressed. Sewer56's PKG tool is the only one that supports (re)compression. Using the PKGTool by thesupersonic16, the PKG files are going to be much larger after they are repacked. When you get the proper .NET Core installed, to use Sewer56's tool it should be as simple as linking CTT-PS to "PKGToolCmd.dll". If all else fails, you can also link PKGTool to this script. It will create larger uncompressed PKG files, but they will work the same.

If you haven't seen this post I do suggest checking it out:
https://forums.dolphin-emu.org/Thread-custom-texture-tool-ps-v46-2?pid=482262#pid482262

Aside from all that, you do have your work cut out for you if you intend to translate all the textures. Some textures use alphanumeric characters from a "grid" to spell things out, so I have no idea how they could be translated. For example...

Spoiler: (Show Spoiler)

This texture:

Spells out things like this:

Or this:

Even this:

I have no idea what you could do for that texture and a few others like it.

Thanks, i don't know what did i do, but now it works, i installed a lot of .net cores, visual studio, enabled IIS restarted a lot of times, i was going to give up but now it works Big Grin

Maybe i can use those Japanese kanjis and substitute them to new characters Huh

I think that text fonts are going to be a headache, i don't know how to open those .itf files (is there a way to edit the fonts?), i have to add new characters, or change some unused to ñ and á é í ó ú ¡ ¿, or i will have to omit them until a new tool appears.

thanks for your help,

Now i will start reading that post and start testing.

Edit: what a letdown. i've managed to translate some words but i don't know why it hangs up when i enter the translated menus :feelsbad:

**Bighead** · (This post was last modified: 01-30-2021, 04:53 AM by Bighead.)

I don't know of any public tools that can edit ITF font, but I know few people have done it somehow. I never managed to figure it out. If you are getting crashes or freezes when replacing textures, there is a few reasons that can happen. Here are some things to take note.

- Keep a backup of your vanilla PKG files. When working on the textures, I had kept around complete backups of the "asset" folder which contains D3D11 and D3D11_us. I know its an extra 10+ GB, but its always handy to have a quick backup when you corrupt a PKG file and no longer have the original without re-downloading/repairing the game.

- The new textures should match the original resolution, or some multiple of it. Because of the way this game was programmed, not all textures can be scaled up. When I was making the texture packs, it lined up with when Durante was working on the games so he added a workaround for those textures.

- Some textures do not like the format or extension changed. If you change for example, some RGBA8/ARGB8 textures to DXT5 or vice versa, the game may crash. Same goes for swapping PNG/DDS. This is especially true with the I_SYSTEM.PKG file; I would suggest trying to replace one texture at a time with this one. Also, just try rebuilding vanilla PKG files that don't work modded to see if its actually building correctly (could be a CTT-PS bug). The safest options are using "Source" for both extension and format.

- Aside from what I said above, its usually safe to swap the format for most textures. Skins/Environments don't usually care what the format is as long as it's DDS. Most UI textures prefer to be RGBA8 or ARGB8. Textures that have button prompts are usually the most problematic. You absolutely can not change the format for those, they must remain uncompressed (RGBA8/ARGB8).

brackenhawk · 03-04-2021, 08:31 PM **#1,040**

Apologies if I've set something up weirdly, but this is stopping me using v47.0.b14:

[Image: YOff8N9.png]

I can see there's a toggle for 'Tools Master Path' in the options menu but it's empty and disabled. I've been using an older version (v32.0) alongside texconv without issue but wanted to get up to date.