Skip to content

Skinning structure

Dean Herbert edited this page Jun 4, 2021 · 7 revisions

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.