This page attempts to detail the various intricacies of the skinning system internals, including how fallback, transformer and legacy provider logic intertwines.
Classes
LegacySkinTransformer
The legacy transformer classes exist to change the behaviour of skin lookups based on legacy skin configuration or special cases. This is for cases where we don't want to include the legacy logic within the drawable gameplay implementations themselves.
Importantly, LegacySkinTransformers
always receive - and perform all lookups on - an ISkinSource
, which means the lookups will traverse the full skin lookup stack (Beatmap -> User -> SkinManager).
SkinProvidingContainer
These containers take in a skin to use as a primary source, but also provide a fallback to a parent ISkinSource
via dependency injection. They are themselves re-exposed via DI so gameplay / HUD elements use them as their primary ISkinSource
.
Generally, this will create the ability to perform lookups over multiple skin providers in this order:
- The beatmap (user toggleable)
- The user's skin
- A default implementation (classic or otherwise)
BeatmapSkinProvidingContainer
A special SkinProvidingContainer
which handles the user toggleability of beatmap skinning.
LegacySkin
This is a skin implementation which handles osu-stable
skins (generally packaged as .osk
files). Logic within this class should be limited to parsing legacy config and returning elements if available locally.