Skip to content

Testing Detect Grid ​

A tidy resolution can still be wrong. We check the input's independently known geometry, the detector's decision, and the result that reaches saved settings.

Test against known geometry ​

Synthetic fixtures start with known dimensions, pitch, phase and crop. We can check whether a one-pixel crop changes the estimated pitch, two overlapping lattices become a falsely accepted global grid, or a repeated motif gets mistaken for a coarser parent.

Adversarial cases cover harmonic aliases, fractional scaling, mixed lattices, margins, local periodic panels, partial cells and phase disagreements. Positive controls catch the opposite failure: refusing every input. The test set needs both clear grids and ambiguous pictures where refusing calibration is correct.

Subdivision and rounding ​

Measured period 4 divided by 2 gives pitch 2 and 157 cells across 314 pixels. Forcing 158 cells produces pitch about 1.987 and different boundaries.Measured period 4 divided by 2 gives pitch 2 and 157 cells across 314 pixels. Forcing 158 cells produces pitch about 1.987 and different boundaries.

An earlier subdivision path measured a four-pixel period with two subdivisions, giving a pitch of exactly two. Instead, it halved a nearby coarse estimate to about 1.987 pixels, then tried to fit an integer cell count to the span.

Across 314 pixels, two-pixel spacing gives 157 cells; the substituted spacing gives 158. Cropping to 313 pixels and forcing 157 cells to fit gives approximately 1.994 pixels. Clipping the final cell should not change the spacing of all the preceding ones.

We fixed the calculation to use the measured period's subdivision. Converting pitch to integer dimensions is a later step with its own rounding rules.

Replay the same pictures ​

Pristine real-game sequences preserve animated artwork, layered UI, filtering, camera movement and mode changes. Replaying identical inputs across revisions isolates algorithm changes from changes in the scene or window placement.

Product comparisons replay the same observations, matching a shipped Detect session. We compare estimated geometry, pitch, phase, visible bounds and the calibration that would be saved. Checking extracted observations separately helps locate whether a change came from extraction or scoring.

Real captures also need independently justified geometry: a repeatable wrong answer is still wrong. Persistence tests check that failure, cancellation and failed saves leave the previous calibration intact.

Regression cases from rejected experiments ​

Experiments can improve one scene while introducing false positives or losing valid detections elsewhere. We keep those difficult inputs as regression cases, even when the experimental method is discarded.

A proposed change must pass the wider set and preserve correct saved geometry.

Test the capture path separately ​

Detector math depends on receiving the intended pixels. Cross-backend tests check pristine pre-treatment capture, row order, channel conversion, visible rectangles and nonzero origins. They also exercise cancellation, resource lifetime and failed GPU copies.

Stale, blank or incomplete captures can mislead an otherwise correct estimator. Replay tests cover the math; native backend tests and physical device/game checks cover delivery of those pixels. Capture-path failures should be fixed in the capture path before changing detector thresholds.

Readback and Detect time ​

A Vulkan investigation traced much of a slow Detect to CPU access to GPU readback memory. Preferring compatible cached memory reduced total Detect time without changing the detector.

Time capture scheduling, GPU transfer, CPU access/conversion, extraction and inference separately. Candidate scoring may account for only part of the wait.

Window placement can change the experiment ​

Controlled Windows tests failed with partly offscreen windows and succeeded at the same resolution when fully visible. The reduced capture bounds changed the input.

Record analyzed bounds alongside image dimensions when comparing runs.

Detect time and temporary frame-time spikes ​

Successful controlled runs had median Detect times around two to three seconds, depending on device and path. The explicit capture session, readback and analysis all contribute to that wait. Some games take longer or yield no result.

Frame times can briefly rise during Detect/Re-detect. Capture and analysis stop when the session ends. Physical checks follow the whole interaction: request, capture, decision, save, visible treatment and normal game behavior.