Writing Messages to the Screen in a MAME Driver
One of the side-effects of the new video system is that drivers aren't allowed to write to the UI layer directly. They can call popmessage() to display a popup at the bottom of the screen, but that's about it in the new system. The problem is that a few drivers were displaying important game-related information using the UI font. Specifically, Atari Football was using it to show which plays had been selected, and the Exidy Max-a-Flex system was using it to draw the status of the lamps and timer. It retrospect, it is actually good that these cases broke because the way it was being done before was a big hack. For one thing, it meant that the game screen area was artificially increased to make room for the text. And second, the state of these lamps was not being properly exposed to the outside world (or in the case of Football, it was being changed via the rendering system in addition to being displayed on screen).
Ideally, the state of these indicators should be made visible via the rendering system. This is great, except that in the absence of an external artwork file, there would be no visible indication at all. This is one of the reasons why it's good to have built-in layouts in the MAME code -- even if they are crude approximations of the original artwork, they at least can reflect important functional information. The problem is, built-in layouts can't really reference image files. All they can do is draw rectangles and disks, which is sufficient for basic overlays on top of old black & white games, but isn't really enough to provide textual information.
In order to solve this problem, I've added a couple of new primitives to the layouts. In addition to rect and disk primitives, there are two new primitives: text and led7seg.
The text primitive lets you add text anywhere within the artwork area.
You can specify color and bounds just like the other primitives. The text is drawn using the built-in fixed-width MAME font (even if you have a different UI font), and is centered within the bounds. If there is too much text to fit in the area provided, the font will be squashed horizontally to fit. Here's an example that positions the text "GAME OVER" in red centered within the given rectangle:
<text string="GAME OVER">
<bounds x="0" y="0" height="10" width="200"
/>
<color red="1.0" green="0.0" blue="0.0" /> </text>
The led7seg primitive lets you position a standard 7-segment LED somewhere in the artwork. The LEDs are drawn a high resolution and oversampled down so they look nice. Typically these are used to specify a digit from 0-9. Turbo is one example. To use this, you would typically create an element with multiple states, each state reflecting the corresponding digit. Here's an example that positions a red LED with the number "2" that is only visible with the containing element is in state
"2":
<led7seg pattern="10111010" state="2"> <color red="1.0" green="0.0" blue="0.0" /> </text>
The pattern attribute specifies which of the segments is visible. A 1 means "on", and a 0 means "off". They are specified in the following order:
- Top horizontal segment
- Upper left vertical segment
- Upper right vertical segment
- Middle horizontal segment
- Lower left vertical segment
- Lower right vertical segment
- Bottom horizontal segment
- Decimal point
Using these two new primitives, I've created built-in layouts for the Atari sports games (Football and Baseball), the Sega Z80 scaling games (Turbo, Subroc 3D, Buck Rogers), Taito's Super Speed Race, and the Exidy Max-a-Flex system that display all the essential lamps and score/timing information. Of course, you can continue to use the externally-provided artwork for a better visual appearance, but now it's possible to provide vital lamps and LEDs via the new built-in layouts without affecting the core game screen or abusing the UI system.
Tomorrow I'll write about the second big change coming, which is related to the issue of lamps and other signals output from the arcade PCBs.
