Easier installation of Texture Packs for end-users

[superostrich]

What happens?

Currently the end-user needs to manually create the path for the texture pack they wish to install. This can be cumbersome for those who aren't computer savvy, and potentially confusing since regional releases of the same game have different disc IDs.

Eg. ..\Documents\PPSSPP\PSP\TEXTURES\ULUS10XXX

What should happen?

I would suggest that either;

A) the path ..\PPSSPP\PSP\TEXTURES\ be created automatically. This simplifies the steps to install somewhat, but the issue of regional disc IDs is still present.

-or-

B) Perhaps PPSSPP could look at subfolders in ..\PPSSPP\TEXTURES\ . Each subfolder being a texture pack (regardless of name), and have the textures.ini file could define which disc IDs the pack works with.

Eg.

..\PPSSPP\TEXTURES\John_Doe_MGS-PW-HD\textures.ini
..\PPSSPP\TEXTURES\Snoopy_v_RedBaronHD\textures.ini

-or-

C) Instead of subfolders, texture packs could be zip files in \PPSSPP\Textures (same texture.ini disc ID functionality as option B).

[LunaMoo]

Or D) - explain better to people you're sharing what they should do and include whole path already telling them to confirm overwrite if they already have that folder to make the whole thing more idiot-proof.

Some format or uncompressed archives storing all the files in one place could be nice to have in the future, but the rest is bad idea.
Texture replacement is often used for replacing few textures(ie ui/fonts) in all games, having to read a hundread of ini files and find which ones are for particular game seems like an awful idea that could bother people adding an extra delay on boot. Same for creating lots of empty folders for everyone that uses texture replacement with that being active by default for everyone, that's just bad.

If we really would need to search through all files and read a lot of ini files to find what folders/files should be used or to create empty folders, this should be manually activated option, not something done automatically on boot. Being idiot-proof should not bother normal users and most emulator users aren't a stranger to basic usage of their operating systems.

[superostrich]

So currently if you want to distribute a pack, the minimum level of instructions has to be;

Extract the contents of the zip file to:

US: ..\Documents\PPSSPP\PSP\TEXTURES\ULUS10XXX
JP: ..\Documents\PPSSPP\PSP\TEXTURES\ULJS00XXX
EU: ..\Documents\PPSSPP\PSP\TEXTURES\UCES00XXX

Note: If you are using the portable version of PPSSPP, the install path is: ..\ppsspp\memstick\PSP\TEXTURES\ULUS10XXX

And it assumes the user has a basic understand of how paths work, which isn't a given.

having to read a hundread of ini files and find which ones are for particular game seems like an awful idea that could bother people adding an extra delay on boot.

I can't imagine a scenario where PPSSPP would have to parse hundreds of texture.ini files unless the user has installed hundreds of texture packs.

"Same for creating lots of empty folders for everyone that uses texture replacement with that being active by default for everyone, that's just bad."

Option A) I am only suggesting the ..\PPSSPP\PSP\TEXTURES folder to be created by default. Not for the individual 'discID' folders. Even that small change would make it considerably easier for the end-user.

[LunaMoo]

Creating just textures folder might be fine, but it doesn't seem to do anything to your problem of different game ID's, also if it was enough could be solved by simply including the full path including "Textures" and telling people to confirm on overwrite if it already exists.:P

Either way automatic parse of hundreads of ini files every time game loads is bad I bet even my personal textures folder has enough ini files to be bothersome to automatic on each boot and I'm not even a graphics dude, I just like to replace some ui elements, fonts, sometimes do a partial japanese->english translations via texture replacement or simply mod some specific graphics that I dislike in the game, either due it glitching with increased rendering res or even simply being ugly. Texture replacement has a lot of uses which does not require spending a lot of time.

We also don't have to reinvent the wheel. Dolphin worked on the same thing last year ~ https://gist.github.com/spycrab/9d05056755d8d7908bdb871a99d050bf
Such packs are basically "installed" from a list in the gui. We don't have to follow the same format and the gui certainly would be different, but the general idea of such installable packs is way better than doing it automatically.

[superostrich]

Creating just textures folder might be fine, but it doesn't seem to do anything to your problem of different game ID's

Having that textures folder in-place gives the end-user a guidepost indicating they're in the right spot, it seems like a good short-term quality of life improvement.

also if it was enough could be solved by simply including the full path including "Textures" and telling people to confirm on overwrite if it already exists.:P

For Windows users this is fine, as Windows's default behavior is to prompt the user to merge the contents of the folders. Mac users are presented with the option to replace, which deletes any files that were in the original destination path. Android file managers are a mixed bag as well. Including the textures folder in the archive is potentially destructive; again I'm thinking thinking of non-savvy end-users here.

We also don't have to reinvent the wheel. Dolphin worked on the same thing last year ~ https://gist.github.com/spycrab/9d05056755d8d7908bdb871a99d050bf
Such packs are basically "installed" from a list in the gui. We don't have to follow the same format and the gui certainly would be different, but the general idea of such installable packs is way better than doing it automatically.

Agreed, that looks like an ideal solution.

[i30817]

I'd much prefer if they were in the same place as the game. Optionally or not, i don't care.

They're game data, that should be moved or copied as a unit, treat them like that. If you have to create a subdirectory that's acceptable too.

[hrydgard]

We can already auto-extract zip files that contain homebrew software / demos, maybe we should support the same thing with texture packs. Or just do the easy thing and autocreate the directory. Either way there's plenty to do here for sure. Tagging 1.8.0 for just creating the dir, and do the rest later (or as it gets contributed).

[i30817]

I'd also suggest not making it so that it requires writing on the same dir as the game, because people can and do place games for read only mediums (compression, dvds etc).

A unzipped subdir with the textures is fine (for if you don't want extraction, or a zipped pack that gets extracted or streaming, but not creating the dir on the same dir as the game.

I'm sure this is preaching to the choir, but this is just for my peace mind because i keep games on a compressed read-only partition. Peace out.

[hrydgard]

Dolphin just introduced a format for texture packs, we should maybe follow them to some degree?

[AkiraJkr]

I can't agree with putting the textures on the games folder, that'd be too much hassle and issues for the end user. But I have one idea:

End-User:

1 - Drag'n'Drop the .zip right into the emulator.

2 - The UI may optionally show a option for the user to install the texture pack for a specific version of the game(which is chosen by the texture pack creator the options, which in my case, I would put JP/US/EU for example), and if possible, detect which versions they actually have in their Recents to highlight for them(if not, ignore).

3 - After that, the zip is properly extracted where it should be, and it's installed, ready to use.

What actually happens:

1 - The emulator searches the .zip file for a textures.ini.

2 - After that, it will create a folder according to the version the user picked.

3 - The contents at the folder where textures.ini rests at is thrown at the new folder that was created.

That's just my idea, but I'll go and check that format for Dolphin to see how it works.

EDIT: Checked it out, and it seems like a pretty good idea! I wouldn't mind at all having to adopt to a new format if it is going to benefit end-users. Even some of my ideas here could implemented alongside that.

[AkiraJkr]

Seems to be working well, however, there's a lingering issue, specially for those hosted on GitHub where the master folder is extracted, and not the content inside it.