Skip to content
Zizeeria
Menu

News

Three screens nobody could photograph

Fix

Every picture this project had ever taken of its own client was of the login screen, because the rest are behind a sign-in. Three faults had been shipping in the dark.

The report came with a screenshot, which is the useful kind. Past the sign-in, on the screen that offers to send a character into the world, the painted background stopped two thirds of the way across and everything to the right of that line was washed black. The card sat in the wash. It looked like something had failed to load.

Nothing had. Four of the screens deliberately darken the painting behind them, because they are made of words and a lit stone arch behind a name field is a lit stone arch somebody has to read through. Each of those screens drew that wash for itself — and each of them lives inside the right-hand column of the shell, beside the news panel. So the wash covered the column and stopped at its edge.

The screenshot proved it without anybody needing to run anything. The card centres itself in that column, and in the picture its centre sits at 1357 pixels across a 1920-pixel window, which puts the column’s left edge at 794 — give or take the few pixels of a border, exactly where the line was. Two other explanations were ruled out the same way. The interface scale was not involved, because the capture that looks correct was taken at seventy per cent and its own settings file says so. The darkness value was not involved either, because the settings screen uses the same one and is intact — for the unrelated reason that it hides the news panel and therefore gets the whole width.

The wash is one thing in the shell now, over the painting and under the interface, and the screens ask for it rather than drawing it. It is switched by visibility rather than by opacity, which sounds like a detail and is not: a transparent panel in this engine draws nothing at all, so a wash authored invisible could never have been faded up. The obvious control is the one that cannot work.

The same screen carried a second fault, and it was older. The button that starts the game pointed at the local machine — not at a server, at whatever happened to be running on the player’s own computer, which is nothing. That default is correct in the code and deliberate: a client with no configuration should aim at a zone somebody is knowingly running rather than at a live one. What was missing was the line of configuration that every shipped build should have carried and none ever did.

And a third, on every screen at once. The ornamented plate behind the primary button on each page was cut from the approved artwork with twenty-two pixels of the page behind it baked into each end — opaque, and darker than the card it sits on. That kind of frame draws its ends at a fixed size whatever the button’s width, so those pixels became a black box at each end with the bronze flourish stranded inside. On the widest button it was a fifth of the width. On the settings screen, where the buttons are narrow, it was fifty-nine per cent — more of the button was margin than button.

What connects all three is duller than any of them and matters more. Those screens are behind a sign-in, and the machine this client is built on is not allowed to handle a password. So every picture ever taken of it, in months of work, has been of the login screen. Three faults sat there in plain sight of anybody who had signed in, and nobody who could sign in was looking at the layout.

The fix for that is one switch on the command line that forces a screen. It was written before the wash was repaired, so the repair could be photographed rather than argued about — and the same picture is what confirmed the plate and the server address in one frame. It is not compiled out of the shipping build, which is a decision: a switch that only exists in a build nobody ships is a switch that cannot photograph the build people actually have.