Screens and layout

You tell vPinOps where your playfield, backglass and DMD live. It writes the settings Visual Pinball reads — per table, immediately before it launches — so every table in your library comes up the same way.

DMD is a screen. Score view is one of the things you can put on it.

vPinOps names the four surfaces after the physical screens a cabinet has: playfield, backglass, DMD and topper. That is what you are placing here.

What plays on the DMD screen is a separate choice, made per table, and it is where Visual Pinball’s own vocabulary appears: its plain dots are called the score view ([ScoreView] in the ini), and it is only one of the options — the backglass’s own DMD artwork is another. So DMD is where, score view is what, and on a two-screen cab the score can be drawn into the backglass with no DMD screen involved at all.

Three shapes people actually run

All three work today. Pick the one that matches your room, not the one that sounds like the default.

Cabinet

Playfield, backglass and DMD on three physical displays, in a cab. The boxes you drag map onto the real machine.

Multi-screen desktop

Two or three monitors on a desk. Same idea as a cab, without the woodwork — the backglass takes a second monitor and the DMD a strip of it, or its own.

Single screen

One monitor. The playfield fills it, and the backglass and DMD are either off or composited. A first-class setup, not a fallback.

Desktop mode is not limited to one screen

Cabinet or desktop is a separate choice from how many monitors you have. Desktop mode drives a backglass on one monitor and the playfield and DMD on another perfectly happily — you do not have to call your desk a cabinet to spread out across it.

How you set them up

There are two ways, and most cabinets only ever need the first.

Pick a monitor — from anywhere

Open Screens in OpsLink. Each surface — playfield, backglass, DMD, topper — has its own card, and each card asks which monitor it lives on. Choose one and that surface fills that screen.

That is the whole job for the common case: one surface per monitor, each filling it. You can do it from your phone, standing at the cabinet or sitting somewhere else, which matters because a cab has no keyboard and its own screen may be sideways or showing a broken layout when you most need to fix it.

Draw the box — at the machine

Some layouts need an exact rectangle rather than a whole screen: a DMD strip along the top of the backglass monitor, or a scaled-down cabinet on one desktop display. For those, open the screen designer on the machine itself and drag real windows to where you want them.

It has to be done there, and that is not a limitation we chose — you cannot drag a box onto a display you are not looking at. Everything else about screens can be done remotely.

Note

Both routes write the same stored layout, so they cannot disagree. Pick a monitor and the box is set for you; open the designer afterwards and you are adjusting that same box.

Per table, not just globally

A global layout covers the whole library, and most tables need nothing more. But some tables want a different arrangement, and Visual Pinball supports per-table settings — so vPinOps writes the keys for the table you are launching, at the moment you launch it, rather than making you keep one global compromise.

Note

vPinOps does not write VPinballX.ini until you launch a table. Up to that point your Visual Pinball settings are exactly as you left them.

Visual Pinball’s own settings — which are yours, and which are ours

A few things live in Visual Pinball’s VPinballX.ini rather than in vPinOps, and the split matters: hand-set one of ours and you will watch it change back.

The plugins — three are switched on for you, the rest are yours

Visual Pinball ships its plugins switched off, and a plugin that is off does nothing, silently. So the first time vPinOps launches a table it switches on the three a table cannot do without, where nothing has chosen them yet:

plugin	what it does
PinMAME	loads the ROM, so a machine table runs at all
B2SLegacy	draws the backglass
ScoreView	draws the score display

A plugin you have turned off yourself, in Visual Pinball’s own F12 menu or in the ini, is left off. vPinOps fills a blank; it never argues with a choice.

Everything else is yours to turn on if you use it: FlexDMD or AlphaDMD for the tables that need them, DOF, AltSound, Serum, PUP. In Visual Pinball’s F12 menu while a table is running, or Enable = 1 under the plugin’s [Plugin.*] section of VPinballX.ini.

There are two backglass plugins, and vPinOps writes to both

B2SLegacy and B2S are two plugins with nearly the same name and different key names for the same ideas. Every grill and DMD setting vPinOps writes goes into both sections, so whichever one Visual Pinball is using, the setting reaches it. The switch itself is different: vPinOps only ever turns on B2SLegacy, and only if you have not turned on B2S yourself. If both are on, which one paints the backglass is Visual Pinball’s priority auction, which is the who paints the backglass setting below.

Never leave RefreshRate blank

Put your display’s real rate in [Player] RefreshRate — 60, or whatever your screen runs at.

Blank is not “use the default”. Visual Pinball asks the driver for rate 0, fails to find a display mode, fails to build its sync device, and raises an error dialog you cannot see, because the full-screen shields are drawn over it. What you get is a black screen or an app that looks frozen, and nothing anywhere says why.

What vPinOps writes, so you do not

Leave these alone in the ini. vPinOps writes them immediately before a table launches, so an edit you make by hand is overwritten with nothing said.

• Where each surface goes, how big it is, and which display it is on — the boxes you drag
• PlayfieldFullScreen, BackglassFullScreen, ScoreViewFullScreen and TopperFullScreen — always 0, so the box you drew is the one Visual Pinball honours
• BGSet, the cabinet-versus-desktop view mode — that follows the mode you pick in Settings
• Enable, for the PinMAME, B2SLegacy and ScoreView plugins — set to 1 only where the key is blank. A 0 or a 1 already there is never touched
• Table and music volume, the backglass and DMD overlay settings under [Plugin.B2SLegacy], and whether the grill is hidden — these are written only when you have set them; leave them alone in vPinOps and whatever you chose in Visual Pinball’s own F12 stays put

Which settings you should not hand-edit — and where to set them instead

The two sections above send you into VPinballX.ini on purpose: RefreshRate and the plugin switches are genuinely yours and vPinOps never touches them.

The settings below are different. vPinOps writes them into the ini itself, immediately before a table launches, because that is the only way a whole library ends up consistent. Hand-set one and it reverts on your next launch with nothing said — which reads as vPinOps breaking something, when it is vPinOps doing its job.

set it here, not in the ini	the keys this writes
Screens in OpsLink, or the screen designer	PlayfieldWndX/Y, Width, Height and the same four for Backglass, ScoreView and Topper — the boxes you drag; plus …FullScreen (always 0) and …Display, which names the monitor
Cabinet or desktop, in Settings	BGSet, and ViewCabRotation when you are in cabinet mode
The table’s own page in OpsLink	ScoreViewOutput and the [ScoreView] Priority.* order — what wins the DMD screen
The table’s own page, or the global default in Settings	[Backglass] Priority.B2SLegacy, Priority.B2S and Priority.PUP — who paints the backglass when a table has both a .directb2s and a PuP pack
The first launch	Enable for the PinMAME, B2SLegacy and ScoreView plugins, filled only where blank
The table’s own page in OpsLink	BackglassDMDOverlay / AutoPos and ScoreViewDMDOverlay / AutoPos — where the DMD is drawn
The table’s own page, or the global default in Settings	B2SHideGrill — the backglass grill
Settings	MusicVolume and SoundVolume

⚠ The difference is worth knowing, because it is the whole rule: the first two rows describe your cabinet — what you play on and where your screens are — so vPinOps rewrites them on every launch and nothing else would keep a mixed library straight. The rest are per-table choices, and vPinOps writes those only once you have made one. Leave a table’s setting alone in vPinOps and whatever you chose in Visual Pinball’s own F12 stays exactly as it is.

When a window lands in the wrong place

The run log says whether vPinOps configured that launch at all:

layout -> Guns N' Roses: Written (1 global, 0 per-table, dmd=Unknown)

Written means it configured this launch; UpToDate means what it wanted was already correct. ⚠ Neither the positions nor your DMD choice are logged — dmd= is which kind of DMD window this table has been seen to open before, not a setting. So this tells you whether we wrote at all, and not where anything was sent. Read last-run.log first; the path is on your platform’s install page.

More, including what to check in what order: the backglass or DMD is in the wrong place.

On Linux

Displays are matched on the name SDL gives them, which is the same name Visual Pinball uses, so the two always agree about which screen is which. It is not always the connector name your desktop settings show you, so if a surface opens on the wrong monitor, start with the names in Settings → Screens rather than with the front end.

On Wayland an application cannot place its own windows; the desktop decides. So Visual Pinball’s backglass and score view are put on their monitors by going fullscreen there, which is the one placement Wayland offers. A surface sharing a screen with the playfield is left where it is rather than covering the table.

On Hyprland, a tiling desktop, vPinOps’s own windows are placed the same way: it asks Hyprland to put the wheel, the backglass and the DMD fullscreen on their monitors, and sets window rules for the session so they reopen there. Nothing is written to your Hyprland config. Each surface fills its monitor; a smaller box inside a screen is not kept there yet.