The new rendering system that was introduced at the start of the 0.106
development cycle represents a whole new way of thinking about video in
MAME. This article is the first in an attempt to explain what's really
going on behind the scenes.

The new system is generally rather object oriented, even though it is still
written in straight C. There are a number of fundamental rendering objects
that are used to describe what gets rendered to the screen. We'll first
go over the objects, and then talk about how it all comes together.

One concept to keep in mind while reading this article is that
the rendering system serves as a bridge between the MAME core and the OS-dependent
code (the OSD layer). There are some objects that are primarily outward
facing (i.e., operated on primarily by the OSD layer), and some objects
that are primarily inward facing (i.e., operated on by other core components).

The core outward-facing object in the new rendering system is the render_target.
A render_target is an object that communicates to the core exactly how
the OSD layer would like the final video to look. The OSD layer is responsible
at startup time (in the osd_init callback) for allocating one or more render_targets.
In the most common case, there will be just one render_target allocated
(though in the Windows code if you request more than one screen, then one
render_target will be allocated per screen).

Each render_target contains information about the width, height, orientation,
and pixel aspect ratio of the destination. For example, if you were running
full screen on a 640x480 display, the OSD layer would allocate a render
target and configure it with a width of 640, a height of 480, a standard
orientation (no rotation), and a pixel aspect ratio of 1.0 (assuming your
640x480 was being displayed on a 4:3 screen). This information is used
later by the MAME core when it is time to actually provide the data necessary
to draw the final output.

On the opposite side of the fence, the core inward-facing object in the
new system is the render_container. A render_container is an object
that contains a list of items (lines, quads, or characters) to draw. There
can be any number of render_containers in the system, but the current system
simply allocates one render_container per screen in the game, and an extra
render_container for the user interface. Code in the core is responsible
for adding items to each render_container. For example, at video update
time, the video.c module adds the bitmap for each screen to the render_container
for that screen. In contrast, vector games don't have a bitmap, and so
their update routines add a bunch of lines to the render_container to describe
what should be displayed on its screen.

In addition to holding a list of items to draw, each render_container also
holds several additional rendering parameters, including brightness, contrast,
and gamma controls, as well as scaling and offsetting functions. When applied
to screen-specific render_containers, these controls give most of the common
adjustments present on an actual arcade screen. These controls are now
(as of MAME 0.106u11) all available from the on-screen display menu, and
work independently for each screen in the system.

So, given what's been described so far, there are two separate sets of
objects for rendering. The first set is the collection of render_targets,
which are allocated and managed by the OSD layer. The second set is the
collection of render_containers, which are allocated and managed by the
core. The obvious question is: how to these two sets of objects map to
each other? That is, how do we get the contents of the render_containers
to show up on the render_targets?

The answer is the layout_view. Each render_target object has an
associated layout_view, which describes exactly how the video system should
position and orient all the elements that go to make up the final video
output. These elements can be items from one of four classes: backdrops,
overlays, bezels, or screens. The first three types of elements are artwork
pieces which are static, preloaded, and pre-scaled graphics that are intended
to be intermixed with the screen elements. The screen elements specify
the location and orientation of the render_container that holds the screen
items.

There are several important implications of this setup. First, each render_target
has its own layout_view, completely independent of any other render_targets.
This means that you can have multiple render_targets active at a time,
each with the same layout_view, or completely different layout_views. Second,
there is only one render_container per screen in the system, but multiple
layout_views can reference each screen. In fact, a single layout_view can
even include multiple references to the same screen; this is how the "Cocktail"
view works in the current system.

Where do layout_views come from? From layout (.lay) files. Layout files
are fundamentally just XML descriptions of layout_views, and each layout
file can contain descriptions of multiple layout_views. At startup, MAME
will attempt to load layout files from multiple sources. All layout files
that are found are effectively concatenated together into one big list
of layout_views, which you can dynamically select at runtime in the new
"Video Options" menu.

So, in summary: at startup, the rendering system creates render_containers
for each game screen, and the OSD layer creates render_targets for each
output screen. When a render_target is created, the selected layout files
are loaded in order to create a list of layout_views. These layout_views
describe how to intermix the render_containers for each game screen with
artwork and other adornments to produce the final output in the render_target.

In the next part of this article, I'll talk a bit about how the graphics
actually get assembled and what the mixing rules are.

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PST/-8.0/no DST' instead in /home/aaron8/public_html/index.php on line 34

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PST/-8.0/no DST' instead in /home/aaron8/public_html/index-html.php on line 87