Forty seconds making it smaller

Michele sent us three photos and a forty-second video with no commentary over it. It did not need any. The game fills his screen widthwise and runs off the bottom, and for forty seconds he tries to make it bigger.

It gets smaller.

That part we worked out quickly, and it is the stupider of the two bugs that came out of those forty seconds.

The slider that ran backwards

The game sizes itself to the window. It works out how far the picture can grow while still fitting inside, and on a monitor like Michele’s that comes to 133 per cent. Anyone who wants to decide for themselves gets a slider, and that slider had a fixed ceiling: 100 per cent, never more.

The ceiling went in back in July for the opposite reason. On a screen smaller than our reference format, 100 per cent is already too much, the picture spills over the edges, and a tester had told us so. On a larger monitor the same ceiling does the reverse damage: the most you can reach by hand ends up smaller than what the game picks on its own. In Michele’s case, 56 per cent of his screen area. Next to the slider it said the maximum is the size that fills the screen, and on any monitor above our reference format that sentence was false.

There was a quiet sequel to it. If you did settle on a size you liked, it came back squashed after a restart, and the next time you played the game shrank on its own without anyone touching anything.

Two numbers that are usually the same number

The other half is the reason the game was spilling over at all, and it kept us busy far longer.

In the photos, the settings panel reads 2560 × 1440 and automatic scale 133 per cent. Those are the right numbers for that monitor. Nothing wrong, apparently.

They are the numbers of two different things. The resolution line asks the monitor. The scale, on the other hand, is worked out from the application window. As long as the two measurements agree, telling them apart is pedantry; when they diverge they are the entire problem, and the panel had no way of saying so, because it never showed anyone the window measurement.

The picture, meanwhile, could not be too large for the window. It is built so that it cannot be: the scale is taken from the tighter of the two sides, so the drawing always fits, necessarily. If something ends up off screen, it is not the picture being too big for the window. It is the window being bigger than the monitor.

From there the suspicion moved to the moment the window is created. We were asking it two things at once: put yourself in the corner of this monitor, and go full screen. With a single monitor, or several lined up, the two instructions agree and nothing happens. With three monitors stacked at different heights, and his are, you can see it in the photo of his display settings, the two instructions can be served by different screens: the position from one, the size from the other. What comes out is a window bigger than the monitor it sits on.

The confirmation arrived from another direction. On one of our own multi-monitor machines, that same line was opening applications on a secondary screen that was switched off. It is the same bug seen from somewhere else. The window now opens at the exact size of the monitor and goes full screen afterwards, rather than both at once, and the monitor is the one the pointer is on rather than the one the system calls primary.

What we cannot say

Here comes the uncomfortable part.

The video on its own does not prove the cropping. Every frame that shows the whole monitor is in manual scale, which means inside the slider bug and not the other one; and every frame in automatic is a close-up, with the top edge of the screen out of shot. The one image that holds both together is a photo from 31 July, and there the top edge of the game lines up with the top edge of the screen. Measured on the photo, the black band above the title matches what the game predicts at that scale, within a few pixels.

So Michele’s case is not confirmed. It is reconstructed. We have one monitor here, his setup is not reproducible, and what this version does close for certain is the ambiguity in how we were asking for the window, which is a bug in its own right and had to go regardless.

The panel will tell us the rest. Alongside the monitor resolution there is now the window measurement, and when the two disagree the panel says so. At the next build those two numbers settle it: if they diverge it was this, if they agree the problem is downstream and not ours.

One thing cost us dearly. The button for going back to automatic sizing, the one that looked missing in the photo, was not missing: in automatic mode it does not exist, because there is nothing to go back from. It looked like a bitten-off piece of screen and it was a button doing its job. Half an hour of measurements taken the wrong way round.

The tool that measured too fast

Then there is the trap, and we verified it on ourselves.

To test this, the window gets resized from outside and we read back the scale the game applied. Done in a hurry, the answer came out: picture at scale one, that is, interface off screen. The bug in hand, reproduced, with a number attached. Reloaded and read again after waiting a moment: 133 per cent, correct.

There was no bug. There was a tool asking for the number before the game had finished working it out. It is the worst kind of trap, because it does not produce an error, which you would see: it produces a plausible defect, and you go chasing that. The checks in this version now wait in three stages before reading anything.

With the waiting built in, the game was tried at nine window formats, on the real package rather than the development version: four widescreen sizes up to 4K, a 4:3, a 5:4, an ultrawide and a 16:10. The picture never escapes. When the window is wider than the game’s format, two black bands are left at the sides, and that is not a defect: it is the right thing to do.

A bug closed before it was born

The last version of the day changes nothing, and that is deliberate.

Inside the game there are two lists that get rebuilt whenever something changes: the targets you can pick and the verbs that are lit. They were rebuilt when you changed room, when a piece of story fired, and when your inventory moved. They were not rebuilt when you learned something, which is to say when the game records one of the things you find out along the way.

Today it changes nothing, and that is not an assumption: neither list reads that data. But the day one of them starts to, the bug is born mute. No error and no crash, just a target that does not appear or a verb that stays dark. For whoever is playing, it is an action that does not work, and then does, once you walk back into the room or reload your game.

That is precisely the shape of another report we are still looking into, from a different tester. It does not run through here, we checked, but ruling it out cost an hour, and it is the kind of doubt that comes back identical six months later. Two words in the right place close the question in advance. The twin list, a little further down the same file, already had those two words: it was an oversight, not a decision.

In the meantime

The tester notes have a new section, “If the game does not fit on your screen”: what was happening, how to recognise it, and the two numbers to send us. The same pass turned up a shortcuts line that gave the settings key as the audio key.

The build the testers are holding is still the one from 30 July and it stops working on 6 August. Before we replace it we want to play the game through from start to finish ourselves, without trusting what the checking programs tell us. Then the build.

Thank you Michele. Three photos and forty silent seconds turned up two real bugs and a trap in our own tools that we would never have found looking at the game by ourselves.