How a game gets its mode

OmaCRT identifies each game’s system, selects a line count and updates the television mode when supported games change resolution. This chapter explains scanning, timing policies and per-system defaults.

System settings specify a line count. OmaCRT calculates the timing from that count; values above 288 select an interlaced mode of the configured standard. Interlaced output is currently disabled on the stock-kernel setup, so 480-line systems use a 240p fallback. See The signal for the limitation.

Game identification

Point the scanner at your collection’s existing folders. It identifies games using these sources:

Extensions that name a system on their own.
The words in the folder names above the file, tokenised, so sega_dc, Sega - Dreamcast and DC games all read as Dreamcast while a folder called dcp does not.
The file itself: disc signatures inside images, the names inside a zip archive, cartridge headers, arcade set names.
What you told it last time, for a folder it could not place.

The index records each game’s title, tags, region and disc number. Regional variants share one entry, and multi-disc games appear under their first disc. A system appears in the menus once it contains games. Files can remain in their existing folder layout.

Line counts

Each system has a default line count: 240 for NES, 224 for Super Nintendo and 480 for Dreamcast. Before starting a game, OmaCRT selects the corresponding timing, subject to the interlace fallback above.

One default per system is right for a console and wrong for an arcade board, because a board draws whatever that board drew. OmaCRT therefore remembers the height a game reported, against that game, in ~/.local/state/omacrt/lines.tsv. It asks for that height before the emulator opens. The field rate a core reported is remembered the same way, in rates.tsv beside it.

A count above 288 requires interlace in a 15 kHz frame. The target timings are 480i at 59.94 Hz for 480 lines under NTSC, and 576i at 50 Hz for 576 lines under PAL. Set the line count; you do not need to select a mode name separately.

Output policies

Three policies control how the emulator’s image fits the output:

Wide fixed frame is the default. Output width stays at 2560 pixels; height and refresh follow the game, with heights such as 224, 240, 256 or 288 lines. A CRT draws each line as a continuous sweep, so horizontal scaling does not have to align with fixed pixel columns. Width-only changes can therefore keep the same output mode.

Follow the game uses the core’s width, height and refresh rate with integer scaling. Each resolution change triggers a mode change.

Pinned mode keeps one output mode for the session and scales the game into it. Super Nintendo uses this policy because it can mix widths within a game. Vertical arcade games also use it when they need a frame taller than 240 lines.

Resolution changes during play

The emulator announces the geometry it is drawing, and every change to it, in its own log:

[INFO] [Core] Geometry: 640x480, Aspect: 1.333, FPS: 59.95, ...
[INFO] [Environ] SET_GEOMETRY: 320x240, Aspect: 1.333.

OmaCRT reads that log, but it does not move the output under a running emulator. RetroArch is told the size of its picture once, when it starts, and cannot be told again while it runs. Following a core into a taller frame left the emulator drawing the old height inside the new one: sixteen black lines at the bottom, and the top of the picture pushed up under the overscan. That was a real fault on arcade boards, photographed on Double Dragon.

So a game whose core reports a height other than the one the launch asked for is scaled into the frame it was given, for that session only. The height is written to lines.tsv, and every run after the first asks for the right frame before the emulator opens and puts one game line on one television line.

The scaling is nearest neighbour and not restricted to whole multiples. video_smooth and video_scale_integer are both off, in the base configuration and in every launch, so nothing is interpolated and nothing is blended. Lines are sampled instead: stretching 224 into 240 uses some source lines twice and some once. The result is point sampled and visibly uneven rather than soft.

To skip even the first run, play the game once, or write the line yourself:

/path/to/game.zip<TAB>240

One entry per line, sorted by path, with a single tab between the path and the count. Counts between 144 and 1080 are accepted and anything else is ignored.

Matching vertical resolution preserves details such as menu text. Reducing a 640 by 480 image to 240 lines loses half its vertical detail.

Per-system defaults

Per-system defaults set the core’s initial behaviour. They include latency settings, rendering options and controller choices.

Run-ahead and rewind are enabled for 8- and 16-bit systems and disabled for 3D systems. Run-ahead removes a frame of input lag by running the core twice per frame. Disabling it on systems such as PlayStation and Nintendo 64 avoids that extra processing cost.

Nintendo 64 uses its native resolution with dithering enabled. These defaults retain the low-resolution rendering associated with the original console’s composite output.

Dreamcast’s configured line count is 480. Full-height output would need working interlace; the stock-kernel limitation described in The signal currently requires a 240p fallback.

GameCube and ScummVM also need specific configuration:

The GameCube core uses its own default options. Invalid graphics-option strings have produced a magenta screen instead of an error, so OmaCRT supplies no overrides. The television’s line count still controls output timing.

ScummVM games use a folder of data files. The core needs a small launcher file containing the game ID beside that data. The scanner identifies the game and writes the launcher file. If the game is still inside a disc image, the scan reports it without creating an incomplete configuration.

Television profile

The television profile is separate from game settings. It stores the timing preset, the horizontal and vertical shift, the horizontal size, the sync polarity and a gain for each colour channel. The TV page of the settings changes these values, and the picture changes while you move them.

The shift moves the picture without a change to the line rate, so the television keeps its lock. The horizontal size changes how much of each line carries the picture. A smaller size gives fewer active samples and a narrower picture. The launcher gives the samples to the two porches in equal parts, so the picture stays in the centre. The stock NTSC line can become about 1.14 times wider before the porches reach their minimum.

The colour gains go from 0.70 to 1.30. The display process writes them into the gamma table of the output, so they change everything on the television. Colour bars and a grey ramp show while a gain row is selected. If the grey ramp shows a colour, decrease the gain of that colour, or increase the gains of the other two.

Use the profile’s test-pattern option to run the 240p Test Suite through its core. The grid helps you adjust size and position.

Centring one game

Some games put their picture in a different place, or have a border of their own. To move the picture of one game:

Start the game.
Open the pause menu.
Select Centre picture.
Move the picture with the arrows or the d-pad.
Use the shoulder buttons to choose where the launcher keeps the position: this game, its system, or all games.
Press A to keep the position, or B to restore the previous one.

The page shows the edges of the frame, with two more frames 4 and 8 pixels inside. Count the frames on each side to see how much the television hides. A position for one game replaces the position of its system. The game starts at its saved position the next time.

Emulator mode switching

OmaCRT sets the output mode on the leased connector. The emulator’s own display-mode switching is disabled; that feature uses a different video driver and would require a patched kernel in this setup. In a desktop window, the same setting would not change the television output.