venomalia / dolphintextureextraction-tool Goto Github PK

since I don't know how games convert typical formats like BMP, JPG, PNG internally to display them, I am not be able to calculate the dolphin texture hash.

I spent the last few hours to try differents iso / rvz even few i've done myself by dumping my own physical game, but everytime, even after forcing uknown files format, i got this error:

The House of the Dead Overkill USA .rvz (or .iso) None compression is currently not supported

Any idea on how to fix this?

Using the latest release v1.7.13.1014 I am able to extract less than 2000 textures from the US version of Mario Party 6, but using an older version v1.5.4.531 I am able to get more than 8000 textures.

our tlut hash does not match dolphins yet, so we use the $ placeholder as long as the texture has only one version.

it dumps like half the textures and then crashes
LOG: [10] Extract: files\res\Object\Hzelda\bmdr\ef_triangleat\tex1_32x32_e6cc95d5e33a7e6f_1.png
• mips:0 WrapS:REPEAT WrapT:REPEAT LODBias:0 MinLOD:0 MaxLOD:0
Warning: Material zelda_doubleside_m_v, TexMatrix2Block index out of range: 0
Warning: Material zelda_doubleside_m_v, TexMatrix2Block index out of range: 0
[08] Unknown: files\res\Object\Hoz\evt\event_list.dat ~16.73KB
• Bytes32:[00-00-00-40-00-00-00-08-00-00-05-C0-00-00-00-1D-00-00-0E-D0-00-00-00-4A-00-00-25-F0-00-00-00-68]

DolphinTextureExtraction.tool 64bit v1.8.0.205 2/15/2024
Tasks:4, Force:True, DryRun:False, Enable Mips:True, Raw:True, DolphinMipDetection:True, ArbitraryMipmapDetection:True

[01] Info: Scan "LTRVT097.GM2" recognized as Grasshopper Manufacture GMF2 Grasshopper Model v2.

~END 2/15/2024 2:49:50 AM

Extracted textures: 0
Unsupported files: 0
Unknown files: 0
Extraction rate: ~ 0%
Scan time: .010s

And the the log on the same file, on the version it was working on: v1.7.26.1213
DTE-TextureExtractor 24-02-15_02-55-20.log

Since this game was ported from N64 to NGC in the US it's probably safe to assume the way the textures are stored is a bit different.
All I could get out of it was memory card textures, nothing in-game was extracted.

I have no clue where you would start to try to get it supported but it would be fun to see the original textures.
In my previous attempts to manually dump them all I was getting close to 20k textures I'm guessing that's around how many it has but I'm not 100% certain.

Most of the textures are located in the STAGE.DAT archive. It can be opened with Solidus tool. Link to some MGS tools, including Solidus.

Description:

The following error message can be seen on startup:

Warning: 7-zip DLL could not be found!

If an archive is encountered during extraction, the following error is seen:

[01] Exception: foobar.zip 7z.dll not found

Hi, thanks for the great tool! It works perfect on the GC version of killer7.
If its not too much trouble, would it be possible to make it also work with the killer7 PC port that came out 2018?

I attached two files, one of the Gamecube and one from the PC port.
Maybe I am just not using it right.
GC_map.pak.zip
PC_map.pak.zip
As far as I unterstand, there is a header added on the pc version. It would make extracting images a much smoother experience, if it worked.

Thank you kindly,
sal4

The trauma center games use a 'tpx' file format that is a collection of TPLs.

According to this post:

.TPX files are just containers for .TPL files, however, the palette is a little tricky. The first half is a table with Green and Red values, and the second half is a table with Alpha and Blue values. So basically you need to multiply the number of colors by 4 to get the size of the palette data and then rearrange in the correct order.

I think we've talked about this but figured I'd make a proper issue. Wiiware titles currently require manually extracting using a separate tool and then running this tool. It'd be nice if we had direct support since even Dolphin can't extract files.

Hello! I've been using DTE with Eternal Darkness' files (extracted from the RVZ image using Dolphin). It could only extract a few .png files (and a lot of .tpl files, when the "extract raw files" optiion is selected). I managed to extract a lot more (but not all of them) using this method:

1. I ran the tool Decompress Eternal Darkness.
2. I removed the ".decompressed" part from the filenames of the resulting files.
3. I ran DTE on them.

I combined the results from both the original and decompressed files (by removing the duplicates), using both the default settings of DTE and the modified settings (I set the extraction of Unknown and Raw files to True). Now I have 994 PNG textures, 1826 .tpl files, and a bunch of other unrecognized file formats (.aig, .bin, .gct, .nut, .txd). There are still some textures that I can't find in the PNG's, such as the one of the protagonist, Alexandra Roivas. Could they be locked inside the .tpl files? What else can I do to fully extract all textures (other than playing the game to dump the textures, as that is highly annoying due to Dolphin constantly dumping the frames of animated textures over and over again)?

In my attempt to get this tool working on Linux, I get warnings during building like:

DolphinTextureExtraction-tool/lib/AuroraLip/Common/Extensions/BitmapEx.cs(42,111): warning CA1416: This call site is reachable on all platforms. 'Image.PixelFormat' is only supported on: 'windows'. [DolphinTextureExtraction-tool/lib/AuroraLip/AuroraLib.csproj]

These classes are/will be unavailable on non-Windows systems. So maybe switch to something else to get cross-operating system compatibility.

These are only warnings, so it does run but no textures get dumped and I get exceptions such as:

Exception: wzx_naminori_damage/0F5E2000_naminori_damage/000181C0.GSscene Object reference not set to an instance of an object.
DolphinTextureExtraction.tool:   at DolphinTextureExtraction.TextureExtractor.Save(JUTTexture texture, String& subdirectory) in DolphinTextureExtraction-tool/TextureExtraction tool/Data/TextureExtractor.cs:line 308
   at DolphinTextureExtraction.TextureExtractor.Scan(ScanObjekt so) in DolphinTextureExtraction-tool/TextureExtraction tool/Data/TextureExtractor.cs:line 188

I haven't checked what the real exception is (as in what exception is getting thrown that is caught before erroring out again), but I guess it is related to the above.

I did try adding the suggested config value into the .csproj file, but it doesn't appear to work. I still get the same error.

diff --git a/TextureExtraction tool/DolphinTextureExtraction tool.csproj b/TextureExtraction tool/DolphinTextureExtraction tool.csproj
index b92a024..44f40e4 100644
--- a/TextureExtraction tool/DolphinTextureExtraction tool.csproj       
+++ b/TextureExtraction tool/DolphinTextureExtraction tool.csproj       
@@ -52,4 +52,8 @@
     </None>
   </ItemGroup>
 
-</Project>
\ No newline at end of file
+  <ItemGroup>
+    <RuntimeHostConfigurationOption Include="System.Drawing.EnableUnixSupport" Value="true" />
+  </ItemGroup>
+
+</Project>
diff --git a/lib/AuroraLip/AuroraLib.csproj b/lib/AuroraLip/AuroraLib.csproj
index 1f22632..1176d8c 100644
--- a/lib/AuroraLip/AuroraLib.csproj
+++ b/lib/AuroraLip/AuroraLib.csproj
@@ -33,5 +33,9 @@
     <ProjectReference Include="..\AFSLib\AFSLib.csproj" />
     <ProjectReference Include="..\LibCPK\LibCPK.csproj" />
   </ItemGroup>
-  
-</Project>
\ No newline at end of file
+
+  <ItemGroup>
+    <RuntimeHostConfigurationOption Include="System.Drawing.EnableUnixSupport" Value="true" />
+  </ItemGroup>
+
+</Project>

I mentioned this on the Discord but figured it'd be a good first issue for someone to get to. The hard part of reverse engineering the format for Endless Ocean has already been done, see: https://github.com/NiV-L-A/Endless-Ocean-Files-Converter . We just need to fit it in to the tool's ecosystem.

Hey there! First off, big thanks for this tool! It's been working great for my gamecube games.

I haven't been able to successfully dump any of my Wii games yet, though. I initially thought that was because the Wii ISOs I had were in two parts, due to the dumper I was using, but after producing a single-part ISO for a different game, I have the same issue:

[01] Exception: R92E01.iso Specified key is not a valid size for this algorithm.

Is there anything I can do to look into the root cause of this error?

Hello fellow modder here. First off really excellent work on this as well as your HDcube model, which I had some really great results with. Thank you for your hard work and for sharing it with the community.

So lets say for example you use wwpacker to unpack a Super Mario RPG wad, then using this tool to extract textures, it looks like most of the Wii overlay items comes through but none of the actual sprites sadly. There were issues with the log due to failures, not all was extracted which gives me hope perhaps this is feasible and the sprites/textures just failed to rip. Perhaps support from tools such as YY-CHR or Tile Molester can give some insight?

If we can somehow properly extract sprites/textures from SNES games or other virtual console titles then this tool goes to another level imo. Currently from what I've observed if you dump textures from these types of games Dolphin just dumps the entire screen and some sprites/weird tiles occasionally. At least in my recent SNES virtual console testing. So its not really feasible unless a tool could somehow take the pain out just giving only what we need. Here's hoping 🤞.

it rarely happens that the tool calculates the hash of RGB565, RGB5A3, RGBA32 textures incorrectly

Tool
tex1_359x127_e9dc27ba10d95fb5_5.png

Dolphin (Correct)
tex1_359x127_70c3e35e945510a7_5.png

the tool does not handle arbitrary mipmap detection.

I posted on the Dolphin forums but it sounded like this was the best place to discuss more nuanced things.

I noticed that the method GetDolphinTextureHash has a "UseTlut" boolean that defaults to false, and no call to it passes in "true". However, when compiling and running the program locally, if I pass in a "true" value, I get the output I'm expecting from my test BRES files.

I'm assuming there's some reason it's disabled currently - does it not work properly with all file formats?

If there is risk to enabling it for standard operation, I think it might be worth adding a flag such as -useTlut that sets this boolean to "true". This would allow users to get the full names for textures when they know the format works properly.

Some textures also have the same texture hash but a different tlut hash. To make the -useTlut flag useful, it may be prudent to also disable the part of the code that skips duplicate textures. This could be folded in the -useTlut flag or a separate flag.

Executables can have textures (and other files) in them, but they are directly accessed by code and thus harder to "find".
For example, Pokémon XD Gale of Darkness has some GTX textures in its .DOL file that it "loads" during startup.

Since we can't really rely on trying to search for possible textures by searching for magic values (since formats like GTX doesn't have one), maybe we would have an separate table that for a given executable (identified by file size and some hash) it would show where a texture is located in and what format (via filename?), so that those can also be extracted.