THE MYSTERY OF THE SANTA MARIA
RSS
← Devlog
v0.44.9 · testing · interface · accessibility · verification

The monitor remembered

A woman sitting in the dark in front of a failing industrial monitor, her face cut by bands of magenta and green light

Mauro opened the game for the first time and found the interface shaking. Not the kind of flicker you have to look at twice to be sure of. The kind that makes you turn your head away after a minute.

He did what a serious tester does. He recorded his screen from the computer, so we could see what he was talking about.

There was nothing in the recording. Steady image, sharp text, no trace of what he had in front of his eyes.

Then he went looking on his own and found the cause. In his NVIDIA control panel, vertical sync was set to “Fast”, and not just for our game: for every program running on that machine. He put it back, and the problem went away.

The story could have ended there. One unfortunate setting on one computer, fixed by the person who had it. You say thank you and move on.

The answer that stopped us filing it away

We sent him seven questions, because before saying “it’s the driver” it helps to know what you are talking about. The first one was the obvious one: did it happen outside the game too?

No. Not on the desktop, not in other applications, nowhere else.

That answer turns the reasoning around. If it had been the driver on its own, everything would have shaken. Only ours did. The setting produces nothing by itself: something on our side has to trigger it.

A second answer narrowed things further. The fault was in the menu and the game screen, never in the opening sequence. The opening is a video, the menu is a drawn interface. Two different ways of reaching the glass.

Reproduce it before curing it

On a machine with the same card we set vertical sync to “Fast”, globally, the way he had it, and opened the game.

It shook.

Having it in your hands changes everything: you stop reasoning by hypothesis and start measuring. The first thing to work out was why Mauro’s recording had come out clean, because that oddity already says where the fault lives. A screen capture records the frame the game hands over, and that is fine by definition. The fault lives further along, on the glass.

So we recorded it a different way: phone in hand, pointed at the lit monitor. There it showed, which confirmed that the fault sits where a capture taken from the computer cannot reach.

Filming a screen with a phone, though, always produces a beat between the shutter and the screen’s refresh rate. “You can see it shaking in the video” proves nothing on its own. The proof comes from comparing inside the same clip: the camera is a constant, so if one stretch oscillates and another does not, the difference comes from the screen.

We measured the average brightness of every single frame. On the game’s cover screen, the swing from one frame to the next was 17 levels out of 255. Twenty seconds later, on the menu, it was two tenths. A factor of a hundred, same room, same shot.

What was actually on the glass

Pull six consecutive frames out of the worst stretch and the fault stops being a flicker and turns into something else.

The monitor was alternating between two entire screens. The game’s cover, and the warning page for testers, the one you pass through at startup and which by that point had been closed for minutes. Back and forth, a five frame cycle, as regular as a metronome.

The game cannot draw those two pages together. They are alternative branches of the same condition: one or the other, never both. No frame we produce contains the two of them.

To be certain, we asked the game to photograph what it was drawing at that exact moment, while the eye was seeing the wrong page. Out came the cover, whole and correct.

The game was drawing the right thing. The monitor was showing something else.

The part that moved was the healthy one

By then we had a fairly precise idea, and it was wrong.

The screens that shook were the ones with something animated on them. The still ones did not shake. Four cases out of four. The conclusion wrote itself: animations trigger the fault, so add a switch to turn them off and anyone with the problem gets relief.

Then Simone noticed something while watching the screen shake. There was a rectangle sitting perfectly still: the one around the words “press any key”. Which is to say the only animated element on that screen.

It is the opposite of what we thought, and it explains everything. When an element is animated, the graphics engine gives it a lane of its own and redraws that lane every frame. It always arrives fresh. The rest of the page never changes, so it never gets redrawn, and the copies the monitor reaches for still hold whatever was there before.

The animations were not dirtying the screen. They were the one area staying clean.

The fix

If the problem is that a still surface never gets handed over again, you make it get handed over. The game now keeps an invisible layer over everything that shifts by four thousandths every frame. You cannot see it, it takes nothing away, and it forces the whole image to be redrawn on every screen refresh.

With vertical sync still on “Fast”, the cover, the menu and the game screen went still. No animation switched off, no decision handed to the player.

It is worth saying why we did not add the switch. Three quarters of the game’s animations do not decorate: they tell you something. The dot marking a new note in the log, the signal bar, where you are on the map. Turning them off would have taken information away from people who already have little of it, and in exchange it would have treated a fault they were not causing.

The experiment that works too well

One step deserves telling, because for twenty minutes it had us convinced we had got it wrong.

We removed the layer, and the shaking did not come back.

It looked like a refutation of everything. It was a confirmation instead: the layer had filled every copy with the same image, so the alternation was still running, but between identical copies. Invisible. The proof arrived on its own at the next step, when we started a game: the first frame of the opening sequence would not appear any more, because the content had changed and the old copies had surfaced again.

There is a rule in that which outlives this case. A fix of this kind has to be on all the time. If it waited to notice the problem, it would always arrive one screen too late.

What is left

The interface is fine. The opening sequence is not: video travels on a separate lane that this layer does not touch, and with that setting active the first clip still fails to show up. It is a relative of the other fault rather than the same one, and it will need a cure of its own.

Mauro could have kept his corrected setting to himself and said nothing more. Instead he answered seven questions, suggested reproducing the fault himself, and turned out to be right. That configuration belongs to anyone who plays competitive shooters and has touched their graphics panel once in their life. If it happened to him, it will happen again.

Now, at least this kind of problem should not come up any more.