How to Install Texture Packs / Custom Textures Info

[degasus]

> because textures are hashed twice using both the old and the new method
This should only happen if there are both formats found. If you just use the new format, the old hash isn't used anymore at all.

[Bighead]

Sorry for the mistake, don't want to spread false info. It's all a lot to take in, which is why I wanted to write all this down while still fresh in my brain. I think I understand, if the new format is found for a texture then it just doesn't even look for the old format at all? What if it doesn't find a custom texture in the new format, does it still look for the old format for a texture when its loaded? I think that's where its hazy for me.

[Bighead]

(01-29-2015, 10:18 PM)Dan_Tsukasa Wrote: So if I wanted to find away around this, would editing the second use of the texture on the games disc itself actually work then? As it'd be seen as different and get dumped both times, of course I suppose then it'd only work with *my* edited disc, and be basically useless for anyone else unless I went ahead and made a texture patcher for those few files on the disc itself.

That's sounds crazy enough that it just might work. Nobody has attempted this to my knowledge, let me know your results.

(01-29-2015, 10:18 PM)Dan_Tsukasa Wrote: Shouldn't those things have been left untextured? Or were they just confused with something else when it dumped and so the retexture just covered both areas?

If two textures would end up with the same hash, then when the first one dumps, as long as it remains in the dumps folder, that hash/name won't dump again. Hence you won't ever get the second dump unless the first dump was removed before it was seen in game, so that causes number 1: it would remain untextured and never seen as a dump, especially if both are loaded at the same area... first texture loaded always wins. And if either that are found are retextured, then number 2: the texture would cover both areas.

[StepDragon]

Question regarding the name conversion feature. Is there any way to create a log output of all the name changes? I can't be the only one who uses the same filename with different types to keep my projects organized. For example I may have multiple files such as:

GAMEID_HASHCODE1_HASH2.png
GAMEID_HASHCODE1_HASH2.pspimage

The second an editable version of the texture from the art program I use (Paint Shop Pro), which contains layer info etc, if I ever needed to modify it again. If there was a log output of all the renaming, I could write a simple script to rename my other files to match. This would save hours of renaming my source files.

I've looked into the dolphin log output window, but it doesn't seem to be able to just output the OSD log to a file. All the log outputs seem to be more under the hood commands.

Any ideas?

EDIT: It looks like I should be able to write a script that watches the directory for changes and creates a log from that. I have a proof of concept working now, but I'll polish it up and post it in a few days.

[Bighead]

So I attempted to give the MipMap generating script more functionality. I wanted to implement some of degasus's suggestions which is difficult, so I thought I'd try an alternative and just completely simplify the process so no thought has to go into it. I'll do a short write up of how it works.

- Install ImageMagick, it's about the only program I could find that can get dimensions and create images through CLI.
- Edit script so that the path points to the installation directory of ImageMagick (default is: C:\Program Files\ImageMagick)
- Copy to the base texture pack folder (SX4E01 for example).
- Run the script. There is an option to apply a sharpness filter to generated mipmaps.
- Type an option and hit Enter. - Option 1 (Weak) is default if no option is entered.
- Now it scans through all folders for mipmap textures (mip1, mip2, etc) and deletes them.
- Finally it generates new mipmaps for all textures found with the "m" flag down to 1x1.
- Displays how many mipmaps were created total.

So this should eliminate the need to know this information about the textures since it will always generate all mips with correct sizes.
- mipmaps have wrong size
- mipmaps aren't complete

These ones might be slightly more difficult....
- the upscaling factor isn't an integer
- the aspect ratio is changed

These 2 kind of go hand in hand in a way. Problem with these suggestions, is batch can only handle 32-bit integers and not reals. This makes it a little more complicating to detect whether or not the new texture dimensions are some multiple of the original texture when division will always end up at a whole number. Can probably be simulated with some trickery, I won't know if I can do it until later....

Edit: Use this script instead!
https://forums.dolphin-emu.org/Thread-unofficial-custom-texture-tool-v3-0

[degasus]

(01-29-2015, 10:04 PM)Bighead Wrote: Sorry for the mistake, don't want to spread false info. It's all a lot to take in, which is why I wanted to write all this down while still fresh in my brain. I think I understand, if the new format is found for a texture then it just doesn't even look for the old format at all? What if it doesn't find a custom texture in the new format, does it still look for the old format for a texture when its loaded? I think that's where its hazy for me.

We scan the folder ons tartup and check which kind of textures exists at all. So if there are no textures in the old format in the directory at all, there is no need to hash all textures and to check if the hash matches anything. The same for the new format. But if there are textures for both formats, we must hash all textures in both ways which is a bit slower on run time. But I doubt you'll notice it as decoding the png or the native texture are both slower than hashing.

[AnyOldName3]

Someone was under the impression at some point that lossy DDS was supported for custom textures, but lossless DDS wasn't. I can't remember the details, but while we're on the subject of custom textures, can someone with actual knowledge comment on this?

[StripTheSoul]

As far as I know only Ishiiruka supported DDS.

@ Degasus: The changed custom texture format doesn't help with textures which have been dumped with texture cache accuracy at SAFE, right? Because I still have to put it to SAFE to get the texture packs for SMG and SMS to load. A pity, but at least now this cannot happen again with new packs

[frozenwings]

@StripTheSoul: You are correct. Only the new hashes ignore the texture cache accuracy. Hashes previously dumped with the old system must still obey the old rules, such as the texture accuracy being set to the same setting they were dumped at.

Someone will have to convert the pack by using the old hashes and playing with the texture accuracy set to safe (or whichever setting they were dumped at). Once the textures are in the new format, you won't have to worry about the texture accuracy settings any longer.

[StripTheSoul]

Hm, so I play at SAFE with the pack and select both, custom textures and dumping? Or what?
Because playing the game at SAFE is a pain for my machine, but since it's mostly just HUD stuff, it'd mostly be dumped in a few minutes I guess...