How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix a GameMaker Debug Overlay Drawn in the Wrong Place When Zoomed

Q: What causes a GameMaker debug overlay drawn in the wrong place when zoomed?

Debug text and stats are drawn in the Draw event using room coordinates, so camera zoom and view offset move and scale the overlay instead of keeping it screen-fixed.

Quick answer: Draw FPS and stats in the Draw GUI event using GUI coordinates, and draw world-space gizmos in the Draw event in room coordinates, keeping the two separate.

Your GameMaker debug FPS text drifts and shrinks when the camera zooms because it is drawn in the world Draw event. Screen-anchored debug HUD must be drawn in the Draw GUI event, which uses fixed GUI-space coordinates.

How to fix it

1. Draw HUD text in Draw GUI

Move FPS, stats, and any screen-anchored debug text to the Draw GUI event. It uses GUI coordinates that ignore camera position and zoom, so the overlay stays put.

2. Keep world gizmos in Draw

Draw debug gizmos that mark world positions (collision boxes, paths) in the normal Draw event in room coordinates, so they track objects as the camera moves.

3. Set GUI size explicitly

Call display_set_gui_size so the GUI layer matches your target resolution, otherwise text scales unexpectedly across different window sizes.

4. Toggle the whole overlay cleanly

Gate both events behind one debug flag so the overlay can be turned off entirely without leaving stray world-space gizmos behind.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every GameMaker error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

Ship the fix, watch the signature disappear from the next build. That's how you know it's really gone.