Player plugin system, native outputs and shared native windows

[freezy]

Adds the plugin system the Player uses to load optional integrations (PinUP, DMD, B2S backglasses, …), plus the shared services those plugins need.

Plugin system (VisualPinball.Plugins, MIT)

• Player lifecycle hooks, plugin descriptors, ordering and capability resolution.
• A declarative configuration schema with global and per-game scopes, discovery catalogs, validation, actions, previews and live reconfiguration. The Player renders the settings UI.
• A resource registry through which gamelogic engines publish controllers, displays, audio and surfaces. Plugins bind to these resources instead of to engine types.
• Global settings that plugins can expose on shared Player pages, such as the volume mixer, and mechanical sound gain.

Native outputs and segment displays

• A new ResourceKind.Outputs carries every lamp, solenoid, GI string and mech by the controller's own number, with its value semantics (binary, levels, physical, position) and a poll-end marker. It is separate from the mapped Controller resource, so role-less controller bindings stay unambiguous.
• Engines opt in through IGamelogicNativeOutputs.
• Height-one displays are published as Segments resources. Each announces its layout, order and element count before its first frame.
• Choice, action and validation requests carry the selected table package (PluginPackageReference).

Shared native windows

• One native library, VisualPinballNativeWindows (VPNW_ API), presents a Unity render texture in a borderless desktop window:
  • Windows: Direct3D 11/12 with DirectComposition.
  • macOS: Metal.
  • Linux: Vulkan/X11.
• It was extracted from PinUP so every plugin can use it. PinUP and the B2S backglass plugin both do.
• The sources and test fixtures are in VisualPinball.Native~/NativeWindows. Binaries are built locally and gitignored, like NativeInput's; only their .meta files are committed.
• On the managed side, VisualPinball.Unity gets NativeWindowSurface and a shared NativeWindowHost presenter.
• The macOS library has not been built yet.

Other

• Insert shaders required by the standalone player are included in builds.
• Standalone table reads use runtime ZIP streams.

Related PRs

All of these are on the feat/player-plugins branch:

• VisualPinball.Engine.PinMAME
• VisualPinball.Engine.PinUp
• VisualPinball.Engine.Player
• VisualPinball.Engine.Player.Hdrp

[greptile-apps]

Confidence Score: 5/5

[High impact] The latest changes appear safe to merge; no new actionable issue was found.

Summary

Adds the Player plugin contracts, settings store, resource streams and shared native windows.

• The Player can load plugins through shared lifecycle and settings contracts.
• Plugins can bind game displays, controllers, audio, and native outputs through shared resources.
• Plugins can show Unity textures in shared borderless desktop windows.
• Table scenes can show plugin output on named cabinet screens.
• Standalone table reads use runtime ZIP streams, and Player builds include insert shaders.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Engine[Gamelogic engine] --> Resources[Shared resource registry]
  Settings[Saved plugin settings] --> Host[Plugin host]
  Host --> Plugins[Optional integrations]
  Resources --> Plugins
  Plugins --> Surfaces[Unity textures]
  Surfaces --> Cabinet[Cabinet screens]
  Surfaces --> Windows[Shared native windows]

Loading

_{Reviews (13) · Last reviewed commit: "packaging: resolve flasher insert bulbs ..." · Reviewed by Greptile}