Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VideoCommon: Allow texture folders to be determined by a <gameid>.txt #8628

Open
wants to merge 1 commit into
base: master
from

Conversation

@iwubcode
Copy link
Contributor

iwubcode commented Feb 13, 2020

Currently, in your "Load" folder, you have a bunch of 3 letter or possibly more folders that reference some game. Wouldn't it be nice if you instead could have a nice native language name instead? Instead of "SLS", you could have "The Last Story".

Well now you can!

You only need to put a "SLS.txt" file in your directory and that's enough to tell Dolphin that is a directory of textures for "The Last Story".

This resolves two issues, neither were made on the issue tracker as far as I know:

  • A user on the forum made a post in feature requests and they wanted the ability to have textures be read from subfolders. They referenced a pack that might be stored on github where downloading automatically adds a subfolder.
  • Admentus currently has to add multiple symlinks for his Majora's Mask / Ocarina of Time project so that all the textures can be shared. Now he can just add multiple .txt to the folder and all will be picked up on load.
@iwubcode iwubcode force-pushed the iwubcode:texturepack_game_id_file branch from 3a5650a to 0378243 Feb 13, 2020
Source/Core/VideoCommon/HiresTextures.cpp Outdated Show resolved Hide resolved
Source/Core/VideoCommon/HiresTextures.cpp Outdated Show resolved Hide resolved
Source/Core/VideoCommon/HiresTextures.cpp Outdated Show resolved Hide resolved
Source/Core/VideoCommon/HiresTextures.cpp Outdated Show resolved Hide resolved
@Admentus64

This comment has been minimized.

Copy link

Admentus64 commented Feb 13, 2020

Works exactly like it says it does.

I noticed the following, bug or intended:

The texture pack does not load if the name of the texture pack folder is set to the first three characters of the GameID, even if a .txt file is added within the folder.

Testing with GameID: PZLE01
WORKS "PZLE01" folder with "PZL.txt" within
WORKS "Zelda 64 4K" folder with "PZL.txt" within
WORKS "Zelda 64 4K" folder with "PZLE01.txt" within
WORKS "PZLE01" folder without "PZL.txt" or "PZLE01.txt" within
DOES NOT WORK "PZL" folder with "PZLE01.txt" within
DOES NOT WORK "PZL" folder with "PZL.txt" within
DOES NOT WORK "PZL" folder without "PZL.txt" or "PZLE01.txt" within

I can confirm that the .txt file for PZLE01 (NTSC-U) can either be named "PZL.txt" (Global) or "PZLE01.txt" (NTSC-U). Naming it "PZLP01.txt" (PAL) obviously does not load the texture pack.

Basicially you have to give the texture pack folder any name other than the first three characters of the GameID.

I don't know whatever this was intended or not, but it can seem a bit confusing when a texture pack will not load because of the texture pack folder name itself. The texture pack folder still be named with the complete GameID without a .txt file for it, but the option to name a texture pack folder with the first three GameID characters without (or with) a .txt is gone.

Loading the texture pack folder named as "PZL" with a "NAC.txt" file within while loading Ocarina of Time (Virtual Console) (NACE01) does work however, so you can load a texture pack folder named with only three GameID characters as long the game that is being booted has a different GameID.

Tested with the following GameID's for the Zelda 64 4K Texture Pack (https://forums.dolphin-emu.org/Thread-zelda-64-uhd-v4-1-2020-01-22):

  • PZL (Ocarina of Time and Majora's Mask for the GameCube)
  • REL (Extracted Collector's Edition .TGC file)
  • D43 (Ocarina of Time and Master Quest for the GameCube)
  • NAC (Ocarina of Time for the Virtual Console)
  • NAR (Majora's Mask for the Virtual Console)
  • NAG (custom patched Dawn & Dusk rom hack as part of the texture pack)
  • NGZ (custom patched injected practice rom)

This eliminates the need for symbolic links through Windows. It also cleans up the "Load" folder with unnecessary symbolic link folders.

A nice bonus, texture packs can now be given any name the user or texture pack author would like, which makes it easier to recognize the texture pack at first glance.

My only suggestion for improvement would be the following:

Use a single .txt file, where each new line entry contains the GameID.

Ex. "Load.txt" with the following lines
PZL
REL
D43
NAC
NAR
NAG

Which cleans up some space within the texture pack folder itself (aka, less files). But this is just extremely nitpicking from me. The solution as it stands now is already by far a great improvement and probably doesn't really need that much refining.

Having a similar concept for texture file hashes itself would be great as well (aka, one texture file that can be re-used for multiple different texture hashes), but I realize that's out of the scope for this PR.

@iwubcode

This comment was marked as outdated.

Copy link
Contributor Author

iwubcode commented Feb 13, 2020

Thank you @Admentus64 for all the testing / feedback.

The texture pack does not load if the name of the texture pack folder is set to the first three characters of the GameID, even if a .txt file is added within the folder.

This was actually intentional. I prioritize the original behavior over the '.txt' solution. Maybe I shouldn't though. I'd be curious what other users think?

@iwubcode iwubcode force-pushed the iwubcode:texturepack_game_id_file branch from 0378243 to ce9e316 Feb 13, 2020
@iwubcode

This comment was marked as outdated.

Copy link
Contributor Author

iwubcode commented Feb 13, 2020

Originally, I was worried about multiple texture packs overriding each other. That's why it now errors if there's more than one pack with a <gameid>.txt.

I thought this scenario would be rather uncommon. Until I thought about dynamic input textures. It's possible there will be a pack with <gameid>.txt and then dynamic input texture pack which generates GAMEID folder. This means that Dolphin would read GAMEID folder and completely ignore the pack.

That's going to make this a bit more complicated. But because of that, I will mark this WIP for now.

@iwubcode iwubcode changed the title VideoCommon: Allow texture folders to be determined by a <gameid>.txt WIP: VideoCommon: Allow texture folders to be determined by a <gameid>.txt Feb 13, 2020
@iwubcode iwubcode force-pushed the iwubcode:texturepack_game_id_file branch from ce9e316 to 2c3664e Feb 14, 2020
@iwubcode

This comment has been minimized.

Copy link
Contributor Author

iwubcode commented Feb 14, 2020

@Admentus64 - your 'not' working cases should now work. Please retest when you have time.

All - I now support loading multiple texture folders, as long as they match the gameid specified. I log an error if there are any textures that were already handled by another pack. This change is to make things work nicely with dynamic input textures and resource packs. In the near future I plan to update the resource packs to properly handle ordering in this scenario (right now the ordering is based off the file system).

@iwubcode iwubcode changed the title WIP: VideoCommon: Allow texture folders to be determined by a <gameid>.txt VideoCommon: Allow texture folders to be determined by a <gameid>.txt Feb 14, 2020
@Admentus64

This comment has been minimized.

Copy link

Admentus64 commented Feb 14, 2020

@iwubcode

I can confirm all cases I described before once again and now they all now fully work. Thus the texture pack will also load if the folder name is set to the first three characters of the GameID, with or without a corresponding .txt file.

In addition I tried dropping a PZL.txt into multiple folders while prefetching textures:

  • Only PZL folder: 6219 MB
  • Two additional texture pack folders (which are not related): 8583 MB

In other words, you can also load textures from multiple texture pack folders. Generally it would be a bad idea for users to start dropping txt files in every folder they have (through honestly, that would be the own fault for doing so), but it actually has a nice feature to it as well, since texture pack creators could essentially split their texture pack into multiple folders.

I don't see any issues anymore with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.