Custom Texture Tool PS v50.1

[Admentus]

The Master Path and the path where I have the CTT are different.

The Master Path for me is D:\Programs\Textures\. Here are all the texture tool programs and the temp folder located.
The CTT path for me is G:\Emulation HD Textures\Custom Texture Tool PS\. Here is the CTT located and any textures I will be processing.

[Bighead]

Thanks that explains it! This is a scenario I wouldn't have even thought of since it triggers the same conditions if the input folder is the script path. Process Selected being unique works with the textures in the Temp Folder rather than the input folder, and since you have it in the same location as the tools, the check was failing. Hopefully I covered all cases this time.

I finally finished all my initial goals, so I'll start work on those "type 2" textures soon.
http://www.mediafire.com/file/jdqqsqqu5im6bay/Custom_Texture_Tool_PS_v43.0.b6.zip/file

The "Split Textures" UI has been reworked, plus a few other unrelated changes. The check that was failing should now be fixed. Text boxes now auto-clear when you click on them. Also fixed some alignment issues on the "Combine Textures" UI.

I have to say I'm quite happy these options have finally started to reach their full potential. When I first created them I realized they wouldn't be useful for OoT because of the overlap problem (you and I had a small exchange 3 years ago actually). I've always wanted to do more with them, and it's nice I also get to prove that "past me" was wrong. At the time my best idea was to make it so you can edit each button individually, set crop boundaries, forced output res, some other stuff. I even started working on some UI for it, but it wasn't long before I realized that it was becoming far too convoluted and scrapped the idea and failed to think of anything better.

It wasn't until years later (or a week or two ago) when I seen those upscales on your thread that the gears started turning. A single value named "overlap" that simulates stacking the edges (but not really) for ALL columns and rows and that would solve the UI presentation issue. It's probably for the better that it took me this long as I definitely wouldn't have been able to make anything close to what I did now and would have taken me weeks longer.

[Admentus]

Yup, it works once again.

Hehe, thanks for your dedication on making it much easier to port those backgrounds for Ocarina of Time. I am currently going through the Kokiri Forest houses (type 1 backgrounds).

[e2zippo]

You guys are awesome, wow! Just out of curiosity, it would be possible to do these backgrounds manually as well right, imagine if Nerrel would tackle these by hand, they could potentially look amazing!
Upscaling is awesome and it's quite a big leap, but I can't help but think how good they could look if done by hand. But I guess that process would be a real pain in ass!

Anyway, thanks a bunch!

[Admentus]

(08-17-2019, 10:46 PM)e2zippo Wrote: You guys are awesome, wow! Just out of curiosity, it would be possible to do these backgrounds manually as well right, imagine if Nerrel would tackle these by hand, they could potentially look amazing!
Upscaling is awesome and it's quite a big leap, but I can't help but think how good they could look if done by hand. But I guess that process would be a real pain in ass!

Anyway, thanks a bunch!

A few backgrounds are hand-drawn, such as Link's House - Side View.

But you really don't want to draw them by hand. There are about 4.620 textures to redraw then. That's one-third of all the textures of Ocarina of Time and Majora's Mask combined (backgrounds excluded). That's just insane. But it can be done I guess. The problem is just that it isn't really worth the time and investment. Most of these backgrounds are only used once. That's a lot of work for something you don't often visit. Hyrule Castle Town Market would be the exception being a important location to return to several times. I mean, how often do you actually visit Mido's House... Or Link's House. A lot of textures which have been re-textured are easily adjustable in other cases they are being used, which makes the time and investment more worth it.

[Bighead]

I can see why you requested support for these textures. It wasn't so bad in the grid, I dumped the temple of time, tossed them in, and seen if i could blindly assemble it. Only took a few minutes. I then checked it against the game, then built it in GIMP. Bleh. Just putting one of these together made me livid.

Spoiler: (Show Spoiler)

This will require higher maximums for rows and columns. I locked it at 18 and I felt that was already too many. I've experimented with large numbers, menu creation can lag a bit, higher numbers yet will crash PowerShell. I also don't want to make one max higher or lower than the other as that is just an artificial limitation, so I'll settle on 40x40. I doubt anyone would actually have a need for this, as that amounts to 1600 images. I can only hope nobody would attempt to actually try to combine (or split) this many.

Spoiler: (Show Spoiler)

It is advantageous having direct control over the button sizes rather than the ratios to fit weird textures like these. I set the size to 750x20 which is fairly close to the shape of these long rectangles. I'm not sure how to handle these textures yet (interface wise), as this is a very specialized method that will only ever be used for Zelda:OoT, and I try to make all the main options generalized. I'm leaning towards some sub-menu where a list of these special circumstances can be collected, kind of like some emulators have a "hacks" tab. There I can move the checkbox for the auto-build method for the first type, and include some cropping method for this type. +Anything that may arise in the future.

(08-17-2019, 10:46 PM)e2zippo Wrote: You guys are awesome, wow! Just out of curiosity, it would be possible to do these backgrounds manually as well right, imagine if Nerrel would tackle these by hand, they could potentially look amazing!
Upscaling is awesome and it's quite a big leap, but I can't help but think how good they could look if done by hand. But I guess that process would be a real pain in ass!

Anyway, thanks a bunch!

Just to add my two cents: it would be possible, but as Admentus says it would be very time consuming for little gain. But, if anyone really wanted to take up that task, at least there is now tools that exist to ease that burden. Reworking the texture was only a small part of the work, combining it properly so it can be retextured, then splitting it manually/properly after its retextured... I couldn't even imagine taking up that task without going insane. But, at least now its not out of the realm of possibility since most of that can be automated.

[Admentus]

(08-17-2019, 11:53 PM)Bighead Wrote: I'm not sure how to handle these textures yet (interface wise), as this is a very specialized method that will only ever be used for Zelda:OoT, and I try to make all the main options generalized. I'm leaning towards some sub-menu where a list of these special circumstances can be collected, kind of like some emulators have a "hacks" tab. There I can move the checkbox for the auto-build method for the first type, and include some cropping method for this type. +Anything that may arise in the future.

Perhaps settings for Ocarina of Time could be part of a new mode. You currently have Dolphin Mode, Export Mode and ToCS Mode. Perhaps a fourth mode for Ocarina of Time where these kind of hacks are applied? I also suppose that this new OoT Mode shouldn't follow Dolphin Texture Format names closely. I mostly work with Expert Mode which makes it easier to recognize the combined background files having generic file names.

[Bighead]

That is one solution, but a new mode is not trivial to make. I could copy most of what expert does, but the only difference would be two specialized behaviors in only 1 operation. It would need to warrant many specialized options to be worth the effort. Expert and Dolphin modes are not much different aside from the "tex1" requirement in "Dolphin Mode", and a few less operations in "Expert Mode" but more DDS formats. ToCS got a mode because of its compression format and weird texture formats, and the fact that there were no -good- tools to convert phyre formats to PNG, and zero tools existed that do the inverse.

I thought about it for a bit. This is just a mock-up (a GIMP edit), but something like this might be a bit more practical. On the combine menu, you push the gear button, and you would get access to some special options. I don't know if that's where I would put that button or if thats what it would look like, maybe in the corner, maybe in the front, maybe smaller. But it would be there somewhere in some form.

[Bighead]

Just a small update to say I'm making progress on those "type 2" backgrounds. As mentioned before, rows and cols have a higher max of 40 to allow this arrangement. Button size of 850x20 works pretty well to keep the aspect ratio. Unfortunately, there is no way I see an "auto-arrange" working for these. I looked hard for any consistencies, there was some in the garbage pixels, but its not always there so they are basically useless.

Spoiler: (Show Spoiler)

I was able to come up with a more "generic" option to handle these textures which could be useful in other situations. The new menu allows setting how many pixel rows or columns to crop away from each side when combining, or how many rows and columns to add back in when splitting. The menu can be accessed from both combine and split options. There are so few options that I didn't feel the need to split them across two menus. I also tossed the "auto arrange" method on here.

Removing garbage pixels will not work if "Inner Pixel Overlap" is set to anything above "0".

Spoiler: (Show Spoiler)

Fortunately 95% of the code could be reused from the "overlap" method since this is just a simpler version of that, so it only took a few minutes to get it to work (as opposed to all the time creating the GUI for it).

Spoiler: (Show Spoiler)

I still have to make it add back garbage pixels when splitting which will be soon. I figured I'd ask if there is any specific color those garbage pixels should be? Or rather, should I allow a configurable color instead of just filling it with black? Or even back up the garbage pixels to separate images (which would be much more work and I wouldn't want to do it unless they actually do something).

[Admentus]

(08-18-2019, 11:46 PM)Bighead Wrote: Just a small update to say I'm making progress on those "type 2" backgrounds. As mentioned before, rows and cols have a higher max of 40 to allow this arrangement. Button size of 850x20 works pretty well to keep the aspect ratio. Unfortunately, there is no way I see an "auto-arrange" working for these. I looked hard for any consistencies, there was some in the garbage pixels, but its not always there so they are basically useless.

Don't worry about it. Type two background are much easier to sort out. There's only one of these backgrounds at a time in an area, while type 1 backgrounds always appear in three, four or five sets. Also, type 2 backgrounds are only sorted in height. There have only rows, no columns. With all the updates you have so far, it definitely has become much easier to sort them out myself. I usually don't watermark them, it's already easy and fast enough to just puzzle the jigsaw in the CTT interface directly itself. I usually hide the font to make it easier to observe if I placed them correctly. Most often, type 2 backgrounds range from a total of 64 to 128 textures per area, while type 1 backgrounds only have 40 textures per area.

(08-18-2019, 11:46 PM)Bighead Wrote:

Spoiler: (Show Spoiler)

I still have to make it add back garbage pixels when splitting which will be soon. I figured I'd ask if there is any specific color those garbage pixels should be? Or rather, should I allow a configurable color instead of just filling it with black? Or even back up the garbage pixels to separate images (which would be much more work and I wouldn't want to do it unless they actually do something).

My method of doing so was to mirror the image (a duplicate of the image layer) into the garbage pixels. The pre-garbage pixels from the right and bottom side of the image will be repeated onto the garbage section in reverse. So far, that technique never caused any issues. What you get is that the same coloring re-appears on the garbage section. The first garbage row or column will be the most important. Leaving the garbage pixels transparent causes some black line issues.



Anyway take your time. I am still busy for the foreseeable near future working on type 2 backgrounds.



Ohh. Sometimes the Custom Texture Tool refuses to start. So... Have I to use a clean file again and set it up again. Any idea why it sometimes fails to start? I can't exactly make it fail on command, it seems to fail starting just at a random point. And I can not turn on the Console Log again since it won't start anymore. In addition, the Tools Master Path, Temp folder and a few settings in Preferences don't get carried over when using the Import Stored Options from a previous version.