菜单
Custom shaders in FlatRedBall2. Use when adding .fx shader files, troubleshooting shader compilation errors (libmojoshader, Wine), or working with precompiled shader XNBs.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Gum Integration in FlatRedBall2. Use when working with UI, HUD, menus, buttons, labels, text display, StackPanel, Panel, layout, Gum Forms controls, Add, AddOverlay, screen-space vs world-space UI, blurry or low-res text, FontSize, text opacity/alpha, or any Gum-related question. Also trigger when user asks about displaying text on screen.
TMX map file creation and editing for FlatRedBall2. Use when creating or modifying Tiled .tmx level files, placing collision tiles, resizing maps, or adding layers. Covers the base template, StandardTileset tile IDs, layer conventions, and CSV tile data format.
Writing headless tests for the Animation Editor (Avalonia). Triggers: AnimationEditor.App.Tests, [AvaloniaFact], TestServices, CreateMainWindow, service wiring in tests, UI-thread RunJobs.
Sprite animation in FlatRedBall2. Use for AnimationChain, AnimationChainList, .achx files, Aseprite/.ase loading, Sprite.PlayAnimation, frame-based texture flipping, looping/non-looping animations, AnimationFinished events, and per-frame collision shapes (hitboxes/hurtboxes, static object collision).
Entities and Factories in FlatRedBall2. Use when working with Entity subclasses, Factory<T>, spawning/creating/destroying entities, entity lifecycle, Add, shape children, CustomInitialize/CustomActivity, or Engine.GetFactory<T>(). Trigger on any entity creation, destruction, or factory question.
Level Data in FlatRedBall2. Use when working with level layouts, level progression, loading TMX maps, generating collision from tile layers, or transitioning between levels. Covers TMX-based level setup, TileShapes generation, and level advancement patterns.
| name | shaders |
| description | Custom shaders in FlatRedBall2. Use when adding .fx shader files, troubleshooting shader compilation errors (libmojoshader, Wine), or working with precompiled shader XNBs. |
FlatRedBall2 ships precompiled .xnb shaders for its built-in Apos.Shapes dependency. These live in src/PrecompiledShaders/ with one subfolder per platform:
| Platform | Subfolder | Set by |
|---|---|---|
| MonoGame DesktopGL | DesktopGL/ | MonoGamePlatform property |
| KNI BlazorGL | BlazorGL/ | KniPlatform property |
Projects import AposShapesPrecompiled.props to use these instead of compiling from source. Unknown platforms fall back to normal Apos.Shapes shader compilation.
These xnbs are duplicated in a second place: the dotnet templates' build folders — templates/frb2-desktop/build/ and templates/frb2-multiplatform/build/ (each has a DesktopGL/; multiplatform also BlazorGL/), plus a copy of AposShapesPrecompiled.props. Any edit to a src/PrecompiledShaders/<platform>/apos-shapes.xnb must be copied byte-for-byte into the matching template folder(s). TemplatePackageReferenceTests fails CI on drift — run it after touching an xnb. This is invariant for any xnb change; the AposShapes.props rebuild checklist frames the sync under a version bump, but it isn't bump-specific.
The package version is centralized in $(AposShapesVersion) (src/PrecompiledShaders/AposShapes.props), imported by the engine. Apos.Shapes ships only buildTransitive assets, so both the version and the SkipAposShapeContent precompiled-XNB skip flow identically whether the package is referenced directly or transitively — sample Desktop projects inherit it from the engine and don't pin it. Re-adding a per-sample pin only reintroduces the drift NU1605 then fails the build on; bump the prop instead.
ShapesBatch.AposShapesVersion (in src/Rendering/Batches/ShapesBatch.cs) is a C# const that can't read MSBuild, so it mirrors $(AposShapesVersion) by hand. In Debug builds, a mismatch against the loaded Apos.Shapes assembly throws InvalidOperationException. See the comment on that constant (and AposShapes.props) for the rebuild checklist.
Adding your own .fx files to a project requires the MonoGame/KNI content pipeline to compile them at build time.
Install the Visual C++ 2013 Redistributable (x64) — the content pipeline's libmojoshader_64.dll depends on it:
winget install Microsoft.VCRedist.2013.x64
Or download from https://www.microsoft.com/download/details.aspx?id=40784.
Without it, builds fail with:
Unable to load DLL 'libmojoshader_64.dll' or one of its dependencies.
The MonoGame content pipeline uses Windows-only tools for shader compilation. Wine must be installed.
Follow the MonoGame setup guide: https://docs.monogame.net/articles/tutorials/building_2d_games/02_getting_started/index.html?tabs=macos#setup-wine-for-effect-compilation-macos-and-linux-only
Shader compilation is not supported on macOS or Linux with the KNI backend. KNI projects must have their shaders compiled on Windows.