dolphin/Source/Core/VideoCommon/HiresTextures.cpp, branch master

VideoCommon: Fix custom texture count in OSD message

2026-08-02T08:11:15+00:00

83dc468 broke the OSD message that shows the number of custom textures.
If Prefetch Custom Textures was disabled, the number would always be 0.

waterfall loading of textures via id to prefer elfid-gameid when launched via elf; fallback to gameid if no match

2026-07-15T19:02:16+00:00

Clean includes

2026-01-24T15:50:10+00:00

Common/FileSearch: Refactor DoFileSearch

2026-01-24T15:50:10+00:00

VideoCommon: separate the concept of a 'resource' from an 'asset'. A resource is potentially multiple assets that are chained together but represent one type of data to the rest of the system. An example is a 'material'. A 'material' is a collection of textures, a custom shader, and some metadata that all comes together to form what the concept of the material is. There will be a 'material' resource. For now, start small by introducing the interface and change our texture loading which used assets from the old resource manager, to an actual resource.

2025-11-23T17:04:24+00:00

VideoCommon: watch texture pack folder for texture reloads (from dynamic input textures)

2025-06-07T04:03:02+00:00

VideoCommon: use CustomResourceManager in the texture cache and hook up to our hires textures

2025-06-07T04:03:02+00:00

Core/VideoCommon: Fix duplicate OSD Custom Textures messages

2024-12-28T08:09:50+00:00

Resolves duplicate OSD messages for Loading and Found custom textures.
VideoBackend initialization results in HiresTexture::Init being called.
We already call HiresTexture::Update when OnNewTitleLoad is called.
Thus we can remove HiresTextures::Init completely as it is redundant.

VideoCommon: instead of using 'CustomTextureData' directly, use 'TextureData' for texture assets, this allows us to provide additional metadata for textures. Such as a sampler or type information (to distinguish cube maps)

2023-10-10T14:58:14+00:00

VideoCommon: Fix std::filesystem::path encoding conversion

2023-08-16T07:56:56+00:00

In std::string, you can store strings using any encoding, but in Dolphin
we have decided to use UTF-8. The problem is that if you convert between
std::string and std::filesystem::path using the built-in methods, the
standard library will make up its own assumption of what encoding you're
using in the std::string. On most OSes this is UTF-8, but on Windows
it's whatever the user's code page is.

What I believe is the C++ standard authors' intended solution to this is
to use std::u8string instead of std::string, but that's a big hassle to
move over to, because there's no convenient way to convert between
std::string and std::u8string. Instead, in Dolphin, we have added helper
functions that convert between std::string and std::filesystem::path in
the manner we want. You *always* have to use these when converting
between std::string and std::filesystem::path, otherwise we get these
kinds of encoding problems that we've been having with custom textures.

Fixes https://bugs.dolphin-emu.org/issues/13328.