MonoGame profiling and packaging
Connects slow frames and memory growth to the actual MonoGame backend and packaged build. It compares the same warmed-up scene and checks shaders, native dependencies and content outside the development environment.
monogame-profiling-platforms
See how it helpsWhen is it useful?
Use when the game works in the IDE but stalls or fails on a player machine.
What does it help you do?
- Separates simulation, drawing, GPU and content-loading costs.
- Compares a representative warmed-up scene and repeated transitions.
- Checks packaged shaders, native dependencies and content paths outside the IDE.
Try asking this
Our desktop shooter runs smoothly in development but stutters in the distributed build. Measure the same busy wave, separating update, draw, GPU and loading costs. Launch from a different directory, verify packaged effects and native files, then report the measured improvement and remaining platform gaps.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
MonoGame — profiling platforms
Use when diagnosing MonoGame frame stalls, memory, content issues or platform packaging.
Version and project gate
Inspect Project and .NET target, MonoGame package/backend, Game loop settings, MGCB files/tool versions, content root, GraphicsProfile, platform libraries and existing screen/state architecture. Never turn a task into an engine upgrade without the user’s intent. Read the version-matching official reference when an API decision depends on it.
Work
Capture backend, runtime, graphics profile and actual target. Separate Update cost from Draw/GPU and content stalls. Compare the same route after warm-up, including frame pacing. Verify packaged native dependencies and content paths outside the IDE.
Deliver
A measured bottleneck and target-specific build/run handover with honest unverified targets. Keep the change in the existing project structure; separate actual observations from the proposed acceptance scenario below.
Failure to prevent
A successful .NET compile does not prove shaders, native libraries or content are available on the player machine.
Acceptance scenario
Run the packaged build, exercise a busy scene and repeat scene transitions; record the actual device and build configuration. Follow the project’s execution and verification permissions. If execution or a target device is unavailable, provide the reproduction steps and name the remaining uncertainty; do not mark it passed.
Scope and sources
This skill belongs to Mox. Agent selection is restricted by Orqestria’s assigned-agent policy, including forced skill selection; instruction text alone is not an access control. These are original task workflows researched from official documentation, not a copied or endorsed vendor skill.
Included files 1
SKILL.md