MAME Multi-Screen Output: Emulated Displays, Layouts, and Host Monitors

Multi-screen MAME setups are easiest to debug when three things are kept separate: the emulated screens defined by the machine, the output windows MAME creates, and the physical monitors on the host. One arcade machine may emulate several CRTs but display them together in one MAME window. Another setup may use several MAME windows, each assigned to a different host monitor. A layout view can arrange one or more emulated screens inside an output window without changing the underlying machine.

This distinction prevents a common configuration mistake: treating a game screen number as if it were the same thing as a host monitor number. MAME screen indexes refer to emulated screen devices. Options such as -screen0 select host displays for output windows. A valid machine layout, window count, and physical monitor assignment must agree with the intended cabinet.

Discover the machine before assigning monitors

Start with the exact MAME build and system short name. Use -listxml to inspect the system description and its display entries, then consult the driver’s source or MAME’s built-in views to determine how many emulated screens it exposes and their orientation. A game’s title or cabinet photo is not enough to infer its screen tags, rotation, pixel aspect ratio, or layout order.

MAME’s layout documentation says screens are numbered from zero in the order they appear in machine configuration. A layout’s <screen index="..."> selects one of those emulated screens; it does not select a monitor attached to Windows, macOS, or Linux. If a screen is optional or a different machine variant does not define it, a view that references a nonexistent screen is invalid and MAME skips that view with a warning.

Try the driver’s built-in views before writing a custom .lay file. MAME generates views for emulated screens and also provides arrangements for multi-screen systems. For systems with more than two screens, the current layout documentation describes generated horizontal, vertical, and tiled arrangements. Those views are useful diagnostic baselines: if all screen images appear in a generated view, the driver exposes them and the remaining work is likely output-window routing or geometry.

The -numscreens option controls how many MAME output windows or screens to create, up to the supported limit documented by the current command-line reference. It does not define how many emulated screen devices the driver has. For example, MAME’s documented Darius example uses three output windows:

mame darius -numscreens 3

One output window can contain a view with multiple emulated screens, which is often appropriate for a single ultrawide monitor or a capture setup. Multiple output windows are more useful when separate host monitors should each show a separate view. Choose the arrangement before tuning scaling; switching from one composite window to three windows changes the geometry problem.

MAME’s documentation also warns that multi-screen operation may not work correctly on some Mac systems. Treat this as a host/backend limitation to verify against the exact MAME build, graphics API, OS version, and monitor arrangement. A failure to create or position output windows is not by itself proof that the emulated screen devices are wrong.

Map output windows to physical displays

First ask MAME to report the displays it sees:

mame darius -numscreens 3 -verbose

Then use the per-window display options, substituting the exact display identifiers reported by that host:

mame darius -numscreens 3 \
  -screen0 "DISPLAY_NAME_0" \
  -screen1 "DISPLAY_NAME_1" \
  -screen2 "DISPLAY_NAME_2"

Display identifiers are platform-specific. MAME’s manual shows Windows display names in a Windows-specific format; do not copy those strings to another OS. The general -screen option applies to all output windows, while -screen0 through -screen3 target individual windows. A window-specific value takes precedence over a general value.

Keep the display topology stable while testing. Docking stations, GPU ports, OS display arrangement, and monitor enumeration can change which identifier corresponds to which physical panel. Record the identifiers from -verbose, the cable/port mapping, OS display layout, and MAME build. If a cabinet must recover after a monitor is reconnected, test a cold boot and a display hot-plug rather than assuming names remain fixed.

Tune geometry per output window

Each output window can have its own physical aspect ratio, requested resolution, and view. MAME provides per-window options such as -aspect0, -resolution0, and -view0, with matching indexes for the other windows. These values describe the host output window. They do not change the emulated game’s internal timing or make a non-square-pixel screen become square-pixel hardware.

For example, the command-line syntax permits a different physical aspect for two windows:

mame pc_cntra -numscreens 2 -aspect0 16:9 -aspect1 5:4

Only use ratios measured from the visible image area of the host displays. The OS desktop mode’s pixel dimensions are not always a reliable physical aspect measurement, especially when scaling or non-square display modes are involved. Start with automatic values, inspect circles and known horizontal/vertical geometry, then change one output window at a time.

Resolution switching is a separate setting. MAME documents that the -resolutionN options request each output resolution and that -switchres is required for switching modes in fullscreen. On modern fixed-resolution LCDs, changing modes may be undesirable; on a carefully configured CRT path it may be intentional. Confirm that the graphics backend supports the requested behavior before making it part of a permanent profile.

Use a custom layout only for a defined view

MAME layout files are XML with a mamelayout root and version 2. A view arranges screen devices and layout elements. The following compact view puts three emulated screens in a horizontal strip; the bounds are illustrative proportions, not a statement about any game’s native pixel dimensions:

<mamelayout version="2">
  <view name="Three screens in a row">
    <screen index="0"><bounds x="0" y="0" width="4" height="3" /></screen>
    <screen index="1"><bounds x="4" y="0" width="4" height="3" /></screen>
    <screen index="2"><bounds x="8" y="0" width="4" height="3" /></screen>
  </view>
</mamelayout>

An index is appropriate when the same machine’s screen order is known. A screen tag is an alternative that identifies a screen relative to the device loading the layout; a layout element must not specify both index and tag. Keep the .lay file tied to the intended system and use MAME’s artwork search path for external layouts. Select the intended view through MAME’s video options or a per-window -viewN setting.

Do not copy the illustrative 4:3 rectangles as universal values. MAME screen devices can have different visible areas, pixel aspect ratios, and rotations. Derive the bounds from the target machine’s output and the chosen host arrangement. If a view mixes bezels or control-panel graphics with the screens, test its collections and overlays separately from the screen routing; an artwork layer can hide a display that was routed correctly.

Diagnose by layer, not by changing everything

Use this sequence when a multi-screen machine looks wrong:

Run a built-in single-screen view for each emulated screen and confirm that the driver produces the expected image.
Use a generated composite view to test the screen order and orientation without host monitor assignment.
Increase -numscreens and verify that MAME creates the expected number of output windows.
Use -verbose and map each output window to a known physical display.
Select a known view per window, then tune aspect and resolution independently.
Check rotation, visible area, and cropping only after the previous layers are stable.

Preserve screenshots and the exact command line at each step. If a screen is black only in one view, inspect the view’s index/tag and layout warning before changing emulated video code. If it is black in every view, investigate driver configuration and emulated screen state. If the image appears on the wrong physical display, fix output assignment rather than swapping driver screen indexes.

Make the installation reproducible

Keep a cabinet record containing MAME version, system short name, output-window count, view names, per-window display identifiers, aspect ratios, resolutions, graphics backend, OS display order, and the .lay file hash. Capture at least one known frame from every emulated screen and one photograph of the physical setup. Re-test after MAME updates, GPU driver changes, operating-system updates, monitor replacement, and docking changes.

A multi-screen setup is accepted when every expected emulated screen appears in the intended view, every output window lands on its assigned host monitor, the image is not unintentionally cropped or stretched, and the arrangement returns after restart. If those conditions are satisfied only with a fragile monitor name or undocumented per-game exception, document the dependency and keep a known-good fallback view.

Related:

Sources: