Rev Diagnostics

Drop it in

One component in a scene, or one line of code, and the overlay is up. There is no prefab to wire, no settings asset to create, and no per-frame garbage of its own — sampling is allocation-tested and the panel does not format strings every frame.

It runs in release builds, not just the editor. Most of the numbers below are worth far more on a device than on your workstation.

What it shows

Performance — current FPS, time-weighted average, 1% low, and frame time, on a live scrolling graph with a configurable target line. Crucially it also shows V-Sync, the target frame rate and the time scale, so a capped frame rate finally explains itself instead of looking like a mystery.

CPU vs GPU — the frame’s time split across both, so a bad frame comes with the side of the machine that caused it. In release builds, with no Player Settings change.

Render — draw calls, batches, SetPass calls, triangles, vertices.

Memory — allocated, reserved and Mono usage, plus GC allocated per frame with its own sparkline, which is how you spot a leak before it becomes a stutter.

Console — the recent log messages themselves, with stack traces, on screen, on the device. Colour-coded, filterable, click a line to expand it. For debugging something with no console attached, this is the whole feature.

Audio — output loudness in dBFS, peak, and a live frequency spectrum.

Environment — Unity version, render pipeline, platform, resolution, refresh rate, graphics API and device, CPU, system and graphics memory, quality level, build type and scripting backend, and your app version.

That last section is the quiet one that matters: it means a screenshot of the overlay is a complete bug report on its own.

It does more than watch

Alerts. Define a rule — FPS below 30 for 5 seconds — and have it take a screenshot, write to the console, pause the editor, or call your own code. Hitches get caught at the moment they happen rather than reconstructed afterwards from a description.

Your own metrics. One line:

RevMetrics.Track("Enemies", () => enemies.Count);

It appears alongside the engine stats, with the same threshold colour-coding. Your gameplay numbers and the engine’s numbers, on the same screen, on the same frame.

Screenshots. One click or F2 grabs the game view with the overlay included.

Drivable from code. The overlay used to expose five members, with every other decision on a private serialized field — so one spawned with Create() could not be configured at all without the Inspector. The tell was in this repository: the asset’s own layout tests reached in with reflection to set useSeparateWindows, because there was no other way.

It now exposes the lot. RevDiagnosticsSection names the twelve parts the settings chips toggle, so a caller can iterate the set — hide everything except Performance — rather than restating it, and code uses the same vocabulary that is on screen. CurrentSnapshot and Metrics expose the samplers the overlay is already running, so reading what is displayed no longer means constructing a second metrics object and paying for every sampler twice, audio FFT included.

Two properties are deliberately missing. graphSamples and consoleCapacity size buffers allocated in Awake, so a property for them would either do nothing at runtime or silently discard the samples already collected. A property that quietly does nothing is the defect this asset exists to prevent, so both stay Inspector-only and the README says why.

Fit and finish

Themeable — Default, Large Text, High Contrast and Compact presets, plus full control over fonts, colours, thresholds and spacing. One combined scrollable window, or separate snap-aligned panels that auto-tile out of overlapping layouts. Every section, the graph and the footer can be toggled at runtime without recompiling.

It ships in its own assembly definitions, requires no packages, and never spams your console.

Verified across every editor it claims

Version 1.0.0 was checked on eight editor versions, from the documented minimum to the newest available — and not by upgrading one project through them. Each editor created a project from scratch and the asset was copied in the way a buyer would: no TextMeshPro, no Input System, no test framework.

Editor	Compile	EditMode
2021.3.45f2 (minimum)	clean	227 run · 222 passed · 0 failed
2022.3.62f2	clean	227 run · 219 passed · 0 failed
6000.0.58f2 · 6000.2.6f2	clean	227 run · 219 passed · 0 failed
6000.3.2f1 · 6000.3.5f2	clean	227 run · 219 passed · 0 failed
6000.5.0f1 · 6000.5.6f1	clean	227 run · 219 passed · 0 failed

That compile check is the “dropped into someone else’s project” case: the asset builds with zero optional dependencies, and the test assemblies exclude themselves rather than erroring.

The differing counts were explained by name, not waved at. The development project runs 238 rather than 227 — exactly InputKeyMappingTests, eleven cases that compile out where the Input System package is absent. The 5 skips on 2021.3 against 8 later are the three UguiLayoutCoverageTests: 2021.3 ships TextMeshPro in its default manifest so they run, and a CLI-created 2022.3+ project has none, so they skip and each says why.

No test present in a clean project is missing from the development one. That sentence is the whole reason for running the matrix.

One detail worth mentioning

The release test suite contains a gate called LinksReleaseGateTests. It fails the build if any link in the package points somewhere other than where it claims to go — a leftover placeholder, or a redirect standing in for the real page.

It exists because a documentation link that quietly rots is a small lie told to everyone who clicks it, and the only reliable way to not ship one is to make the build refuse.