feat(winui): add experimental WinUI sidecar

[cmdr-chara]

Summary

Adds an experimental WinUI 3 sidecar for UndertaleModTool.

The existing WPF application remains the stable editor. The WinUI project is added as a beta interface for browsing and editing GameMaker data files while continuing to use UndertaleModLib for data loading, saving, and resource models.

Changes

• Adds UndertaleModTool.WinUI, a packaged WinUI 3 desktop sidecar project.
• Adds resource browsing, tabs, command input, recent files, and editor surfaces for common resource types.
• Adds preview support for sprites, texture page items, embedded textures, rooms, paths, backgrounds, sounds, and embedded audio.
• Adds in-app audio playback controls for supported embedded/external sound data.
• Defers expensive preview rendering and caches/debounces texture preview work.
• Improves sound export behavior and adds native CLI sound dumping options.
• Adds local perf tooling for script/native export comparisons.
• Adds smoke/compile coverage for the new script and CLI dump paths.

Beta Status

This is intentionally beta. The WinUI sidecar is not meant to replace the WPF editor yet. It is isolated in its own project so it can be tested and iterated without destabilizing the existing UI.

Known remaining risk areas are visual polish, workflow parity with the WPF editor, and broader testing across more GameMaker data files.

Testing

• dotnet build .\UndertaleModTool.sln -c Debug --no-restore
• dotnet test .\UndertaleModTests\UndertaleModTests.csproj -c Debug --no-restore --no-build
• dotnet test .\UndertaleModLibTests\UndertaleModLibTests.csproj -c Debug --no-restore --no-build
• UndertaleModTool.WinUI.exe --smoke-test "C:\Program Files (x86)\Steam\steamapps\common\Undertale\data.win"

Risks

• Large UI-sidecar addition; review is easier by treating UndertaleModTool.WinUI as experimental surface area first.
• WinUI packaged launch behavior differs from direct executable launch during local development.
• The WPF editor remains the stable path for workflows that have not reached parity yet.

[cmdr-chara]

@colinator27 @BenjaminUrquhart Could you take a look when you have time? This is intentionally a beta WinUI sidecar, not meant to replace the WPF editor yet. I’m also fine splitting it if the current PR is too large to review cleanly.

[CST1229]

Honestly, I don't see much reason for this.... WinUI is not cross-platform (Windows-only) so not sure what purpose this would even serve.

[cmdr-chara]

Honestly, I don't see much reason for this.... WinUI is not cross-platform (Windows-only) so not sure what purpose this would even serve.

Fair. I do not want this to be wasted either, so I’m happy to narrow the scope.

Would a Windows-only beta sidecar be acceptable if it stays clearly experimental and separate from the WPF editor, or would you prefer I split out the reusable parts first, like audio export/perf/test improvements?

Also, Grossley seemed to be fine with this change.

[cmdr-chara]

[colinator27]

This is an interesting concept, but unfortunately we have no plans to create any additional dependencies on Windows (or any OS, really) for the foreseeable future. At least, not in a way that we want to maintain here.

[BenjaminUrquhart]

This also conflicts with #2126, which aims to remove the dependency on windows for UI entirely so UTMT can actually work on other operating systems.

[cmdr-chara]

@colinator27 @BenjaminUrquhart thanks for clarifying the direction.

I still want to keep working on this, so I’ll pivot toward the Avalonia/cross-platform direction instead of trying to push WinUI as the maintained path. The WinUI branch can stay as a prototype/reference for UX ideas, and I can split or port useful pieces where they fit.

The main improvements from the prototype that I’d like to carry forward are:

• Faster/lazier preview rendering so large sprites, textures, and rooms are not rendered eagerly.
• More usable texture and sprite previews, including zoom/open/export actions and better page-item linking.
• In-app embedded audio playback/export with richer audio metadata.
• Cleaner resource editor layouts and navigation behavior.

If this direction sounds acceptable, I can start by porting one focused area into the Avalonia work rather than keeping this as a separate Windows UI.

[cmdr-chara]

...Even though Avalonia is kinda basic, to be honest, at least for today's standards.

I either do a personal fork and hope for the best, which actually makes more sense, plus most of the users are from Windows anyway.

[cmdr-chara]

@colinator27 @BenjaminUrquhart Maybe a compromise would be me keeping it as an unofficial Windows-focused fork and maintaining it myself. If it ends up being useful/stable enough, would you be open to linking it somewhere as a community fork, without it being a maintenance burden for the main repo?

[BenjaminUrquhart]

I don't believe we have a place to link forks and such, as stuff we are interested in we prefer merging into the tool proper.

Given that we don't plan on incorporating this UI, I'm going to close the PR now.

[cmdr-chara]

I don't believe we have a place to link forks and such, as stuff we are interested in we prefer merging into the tool proper.

Given that we don't plan on incorporating this UI, I'm going to close the PR now.

By that place, I meant the readme of the main repository; you could simply mention my fork which is exclusively optimized and modelled for Windows.