Dolphin, the GameCube and Wii emulator - Forums

(11-25-2021, 05:49 AM)mikezilla2 Wrote: [ -> ]No Eta up master updates ?

not working on that currently, I'm bussy with my work. Will try to take some time on my vacations.

Thank you Tino, I will test it out really soon. Tomorrow is going to be a busy day, but I'll hopefully find some time.

I can quickly answer the DDS header question though... Yes they are output from both Dolphin Ishiiruka (when dumped as DDS) and the Ishiiruka Tool like that. It's really a non-issue when it comes to Dolphin/Ishiiruka, as both don't care about the header data. The only time it matters is when trying to open them in a raster graphics editor. Since the flags being set, or rather the ones not being set are (non-standard), most programs don't know what to do with them.

I'll try to break it down, but I'm not really good at putting it into words. I am basing it off this chart which I created when reading into the documentation on Microsoft articles.



Here is a texture that would dumped with Ishiiruka or created with Ishiiruka Tool. The 44 here goes against the standard, and all image editors can't open it as is.
- The value 40 means it should have data in the RGB fields, which is only true for uncompressed textures (RGBA8/ARGB8/L8/A8/LA8).
- The added 04 means it has FourCC or rather its compressed (DXT1/DXT3/DXT5). This much is correct.
- In other words, the flag set up in this way is like saying its both compressed and uncompressed at the same time.



Here is a texture created with TexConv compressed DXT3 which has alpha, the sum of flags should be 05 which is most commonly seen in all DXT3/DXT5 textures.
- Since it's a compressed texture, the FourCC field will contain a value (44 58 54 33 = DXT3) so 04 is added.
- DXT3 and DXT5 always have DDPF_AlphaPixels set, so 01 is added. I've never seen a program write a texture with DDP_Alpha (02) flag set.
- Most DXT1 textures don't have alpha, so they end up with a 04 here. I'm not sure if DXT1 has a 05 here if the texture has 1 bit alpha (but I imagine this to be true). Unless DXT1 uses the above mentioned DDP_Alpha (02) flag. I'm not really certain at the moment.



As for the next set of flags, it's uncommon to not see these in DDS textures. Basically all of them always have 08 10 40 regardless of the characteristics of the textures. Maybe most DDS writers do this as a fail safe as it doesn't hurt to have all the flags here, but it does mess things up when they are missing.



At the bare minimum, every DDS texture  should have at least the 10 set, as it says "this is a texture". Some writers do actually correctly write these flags. For example, if a textures does not have mipmaps, it will omit the mipmap and complex flags 08 and 40 but this doesn't seem to be necessary as they always seem to work when included. Most textures include all the flags, even when it doesn't have mipmaps. The DDSCaps_Complex to my knowledge means that it has more than 1 surface, so if it has mipmaps, it is also complex.

But yeah, if you are setting them up this way for a specific reason, then do ignore this. The textures work in Dolphin even with the flags set up this way. The only reason I mention it is because the textures will not open in graphics editors with the way the flags are currently dumped and created in Ishiiruka Tool, and fixing them to the "correct" flags allows them to be opened. The correct flags would only be a minor convenience to make them easier to modify.

(11-25-2021, 01:38 PM)Bighead Wrote: [ -> ]Thank you Tino, I will test it out really soon. Tomorrow is going to be a busy day, but I'll hopefully find some time.

I can quickly answer the DDS header question though... Yes they are output from both Dolphin Ishiiruka (when dumped as DDS) and the Ishiiruka Tool like that. It's really a non-issue when it comes to Dolphin/Ishiiruka, as both don't care about the header data. The only time it matters is when trying to open them in a raster graphics editor. Since the flags being set, or rather the ones not being set are (non-standard), most programs don't know what to do with them.

I'll try to break it down, but I'm not really good at putting it into words. I am basing it off this chart which I created when reading into the documentation on Microsoft articles.



Here is a texture that would dumped with Ishiiruka or created with Ishiiruka Tool. The 44 here goes against the standard, and all image editors can't open it as is.
- The value 40 means it should have data in the RGB fields, which is only true for uncompressed textures (RGBA8/ARGB8/L8/A8/LA8).
- The added 04 means it has FourCC or rather its compressed (DXT1/DXT3/DXT5). This much is correct.
- In other words, the flag set up in this way is like saying its both compressed and uncompressed at the same time.



Here is a texture created with TexConv compressed DXT3 which has alpha, the sum of flags should be 05 which is most commonly seen in all DXT3/DXT5 textures.
- Since it's a compressed texture, the FourCC field will contain a value (44 58 54 33 = DXT3) so 04 is added.
- DXT3 and DXT5 always have DDPF_AlphaPixels set, so 01 is added. I've never seen a program write a texture with DDP_Alpha (02) flag set.
- Most DXT1 textures don't have alpha, so they end up with a 04 here. I'm not sure if DXT1 has a 05 here if the texture has 1 bit alpha (but I imagine this to be true). Unless DXT1 uses the above mentioned DDP_Alpha (02) flag. I'm not really certain at the moment.



As for the next set of flags, it's uncommon to not see these in DDS textures. Basically all of them always have 08 10 40 regardless of the characteristics of the textures. Maybe most DDS writers do this as a fail safe as it doesn't hurt to have all the flags here, but it does mess things up when they are missing.



At the bare minimum, every DDS texture  should have at least the 10 set, as it says "this is a texture". Some writers do actually correctly write these flags. For example, if a textures does not have mipmaps, it will omit the mipmap and complex flags 08 and 40 but this doesn't seem to be necessary as they always seem to work when included. Most textures include all the flags, even when it doesn't have mipmaps. The DDSCaps_Complex to my knowledge means that it has more than 1 surface, so if it has mipmaps, it is also complex.

But yeah, if you are setting them up this way for a specific reason, then do ignore this. The textures work in Dolphin even with the flags set up this way. The only reason I mention it is because the textures will not open in graphics editors with the way the flags are currently dumped and created in Ishiiruka Tool, and fixing them to the "correct" flags allows them to be opened. The correct flags would only be a minor convenience to make them easier to modify.

should be fixed in the latest version

Finally got some time to test (1.2.0), unfortunately I hit a bit of a snag...

I tried to convert some materials to material maps. It refuses to write to any folder I throw at it despite permissions. I tried to run as administrator and that didn't work either.

(11-28-2021, 01:41 PM)Bighead Wrote: [ -> ]Finally got some time to test (1.2.0), unfortunately I hit a bit of a snag...

Spoiler: (Show Spoiler)

I tried to convert some materials to material maps. It refuses to write to any folder I throw at it despite permissions. I tried to run as administrator and that didn't work either.

Never have a problem like that before, uploaded a new version with an unrelated fix. please test if the same happends again.

Same issue unfortunately. It almost appears like it's treating the output path as a file instead of a folder. If I delete the target path, in this case the folder named "Test", it creates a file named Test instead. If the Output folder exists, then it just silently fails.



I created a few test cases here, a batch script, a PS script, and a PS script using "jobs":
https://www.mediafire.com/file/u9hy6fczv0azjnt/IshiirukaTest.7z/file

The result is the same with all of them, if the "Output" folder exists, then nothing is created. If this folder is deleted, Ishiiruka Tool will create a file named "Output". The error I posted before is only shown when using the tool in my texture tool. I am not sure why it shows there and not in the scripts I linked despite the conditions being exactly the same, those just silently fail, but the texture tool somehow manages to extrapolate the error.

Edit: Something I didn't notice before.. If I delete the "Output" folder before generating, then Ishiiruka Tool will create that "Output" file, but also it creates the material map mipmaps in the Input path, but it will not create the material map itself.

Here I deleted the "Output" folder, ran a script that launches Ishiiruka Tool, it created an "Output" file.


But it also created the material map mipmaps in the "Input" folder...

(11-29-2021, 12:34 PM)Bighead Wrote: [ -> ]Same issue unfortunately. It almost appears like it's treating the output path as a file instead of a folder. If I delete the target path, in this case the folder named "Test", it creates a file named Test instead. If the Output folder exists, then it just silently fails.



I created a few test cases here, a batch script, a PS script, and a PS script using "jobs":
https://www.mediafire.com/file/u9hy6fczv0azjnt/IshiirukaTest.7z/file

The result is the same with all of them, if the "Output" folder exists, then nothing is created. If this folder is deleted, Ishiiruka Tool will create a file named "Output". The error I posted before is only shown when using the tool in my texture tool. I am not sure why it shows there and not in the scripts I linked despite the conditions being exactly the same, those just silently fail, but the texture tool somehow manages to extrapolate the error.

Edit: Something I didn't notice before.. If I delete the "Output" folder before generating, then Ishiiruka Tool will create that "Output" file, but also it creates the material map mipmaps in the Input path, but it will not create the material map itself.

Here I deleted the "Output" folder, ran a script that launches Ishiiruka Tool, it created an "Output" file.


But it also created the material map mipmaps in the "Input" folder...

here you can see the output from runnig the tool in my sistem
https://drive.google.com/drive/folders/1flNZxMutCoXachg-pSRUCg8vBVsMQYep?usp=sharing
output is dxt5 output2 is bc7
make it using this configuratgion

ok now i can reproduce it will try to fixit asap

Ok try it now new version uploaded.

Thanks for all the fixes Tino. As far as I can tell, everything seems to be working. Converting materials to PNG, BC5, and BC7 all work as expected. Converting material maps to material maps with other formats using "-frommaterial" is all working as expected. Resizing images with "-w" and "-h" also has no problems. Fantastic work!

The only "issue" I noticed that remains is the DDS headers are still just a bit off by one byte which prevents them from being editable in image programs. Other than that, everything else seems to be working perfect. In the value of "45", the "40" here shouldn't be in compressed textures, but the "5" is correct. So changing the 4 to a 0 makes it work.