How to Install Texture Packs / Custom Textures Info

[frozenwings]

As far as I understand it, changing the texture accuracy no longer has any effect on the chance of hash collisions; it's basically always dumping in "safe" now.

So, basically, I don't think changing from medium to safe will change anything.

This is probably why you've already discovered those 7 new textures.

[Bighead]

(01-29-2015, 06:07 AM)Dan_Tsukasa Wrote: Downside is it will require 2 texture packs for all HD retexture projects, 1 for new dolphin 1 for older (provided people wanted to support older revisions).

As long as your game works in new Dolphin (which it should) there is no reason for a pack to support older versions. Development versions are much faster and stable than the 4.0 release or anything before it, and this gives you a jump start at having a compatible pack before the next stable release.

(01-29-2015, 06:07 AM)Dan_Tsukasa Wrote: With this texture pack would it be possible to have 2 variations of the texture? 1 that loads in one place and 1 that loads in another? With standard Dolphin it dumps a texture with the exact same name,
In the games actual files the texture itself is identical but its in 2 separate folders with 2 entirely different names, so its not like the game simply reuses it, just dolphin does.

(01-29-2015, 07:42 AM)Dan_Tsukasa Wrote: Did a quick test, yeah same issues still there. I wonder why though, the game has 2 separate textures in 2 separate folders (different names, identical image) on the disc, its so frustrating having to have a nice middleground as an artist.

Dolphin doesn't extract the textures from the game, they are read when loaded then given a hash that is calculated from the texels (texture pixels). If two textures are identical, then they will share the same hash, there is no work-around. Dolphin doesn't care where the game stores them on the disc, it just cares where they are used in-game.

(01-29-2015, 06:07 AM)Dan_Tsukasa Wrote: A texture dump using the newest dolphin actually showed me some textures which didn't get dumped at all previously, I even redumped that same area with the old dolphin, same settings, didn't get those 7 new textures using that either, how strange, they must have had the same hash.

Yeah that was nice, Xenoblade was actually dumped with fast and I found 2 map textures I didn't even know existed! Also, changing accuracy does nothing for the new format, custom textures are always hashed with "Safe". Changing the accuarcy is still needed to load/rename old texture packs though.

(01-29-2015, 07:42 AM)Dan_Tsukasa Wrote: This version even loads the old texture packs still, which surprised me, I figured it'd only load the new names, not the old ones, will it always be like this or will 'backwards compatibility' for those older packs be phased out entirely at some point?

I was told it was to be phased out sometime after the next official release. Right now it's actually slower than it should be because textures are hashed twice using both the old and the new method, which becomes pretty redundant after a certain period.

[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.

[Dan_Tsukasa]

(01-29-2015, 03:14 PM)Bighead Wrote: In the games actual files the texture itself is identical but its in 2 separate folders with 2 entirely different names, so its not like the game simply reuses it, just dolphin does.
Dolphin doesn't extract the textures from the game, they are read when loaded then given a hash that is calculated from the texels (texture pixels). If two textures are identical, then they will share the same hash, there is no work-around. Dolphin doesn't care where the game stores them on the disc, it just cares where they are used in-game.

Ah I see, so Dolphin 'sees' that these 2 textures, eventhough they're loaded separately, look 100% identical, and so it ignores one of them once its already hashed the first it doesn't bother to hash the second as it see's no change.
I suppose this is to prevent things like re dumping character textures every time the character is reloaded then, as I imagine that'd happen often (MGSTTS has the Snake texture read to load in every ingame folder for example).
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.

I'd be interesting to see if theres a way around this, a lot of games reuse the same texture a number of times, and being able to have each reuse be custom for the area its in, would be great. Otherwise yeah I suppose just finding a middle ground would have to do.

(01-29-2015, 03:14 PM)Bighead Wrote: Yeah that was nice, Xenoblade was actually dumped with fast and I found 2 map textures I didn't even know existed!

Yeah this was really nice. But I'm confused how it works, I've retextured entire environments before, with nothing left untouched, and it all loaded fine nothing missed out, how does that work if there were textures left undumped previously? 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?

[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.

[Dan_Tsukasa]

(01-29-2015, 11:13 PM)Bighead Wrote: 1: That's sounds crazy enough that it just might work. Nobody has attempted this to my knowledge, let me know your results.

2: 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.

1: I'll have to find a game that people have torn apart and repacked first then, extracting everything from the metal gear games level.dat I can do, along with converting it all to TGA, but converting it back, and then repacking the entire .dat plus the rest of the iso, I can't, at least not unless someone with a lot of talent appears. So if you know of a game that people have been able to take apart, edit and repack, let me know and I'll do a few quick tests with that. Otherwise it'd be really sweet if there was a way to get dolphin to notify me when a hash was the same, and ask if it wants me to simply write that particular hash with a different name so I can still have it load up. I wonder if thats at all possible

2: Ah so this would explain (possibly) why sometimes a retexture gets placed in an area you never wanted it, but theres no actual way of fixing it (with the old method I mean) so people just leave it, and now we're able to detect better we can have an alternate texture for that section and the retexture will fit slightly better.

[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.