Sprinter/mame
2
0
Fork 0
mirror of https://github.com/holub/mame synced 2025-06-04 11:56:28 +03:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

-luaengine_render.cpp: Work around MSVC ambiguous overload error.

Browse Source 
-docs: Clean up a little.
 * Includes typo fixes from Alexander Miller.
This commit is contained in:
Vas Crabb 2020-11-26 13:47:02 +11:00
parent 149a2523fe
commit e8998a9236
5 changed files with 86 additions and 62 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/source/techspecs/layout_files.rst
View File

@ -602,8 +602,8 @@ the state of an active-high output:
.. code-block:: XML
<element name="led" defstate="0">
<rect state="0"><color red="0.43" green="0.35" blue="0.39" /></rect>
<rect state="1"><color red="1.0" green="0.18" blue="0.20" /></rect>
<disk state="0"><color red="0.43" green="0.35" blue="0.39" /></disk>
<disk state="1"><color red="1.0" green="0.18" blue="0.20" /></disk>
</element>
An example element for a button that gives visual feedback when clicked:
@ -773,7 +773,7 @@ The ``orientation`` element supports the following attributes, all of which are
optional:
rotate
If present, applies clockwise rotation in ninety degree implements. Must be
If present, applies clockwise rotation in ninety degree increments. Must be
an integer equal to 0, 90, 180 or 270.
swapxy
Allows the screen, element or group to be mirrored along a line at
@ -1419,7 +1419,7 @@ in case of an I/O error. If an output file name is specified, the file will be
created/overwritten on success or removed on failure.
To check a layout file for common errors, run the script with the path to the
file no check and no output file name or base variable name. For example:
file to check and no output file name or base variable name. For example:
**python scripts/build/complay.py artwork/dino/default.lay**

104
docs/source/techspecs/luaengine.rst
View File

@ -4,41 +4,53 @@ Scripting MAME via LUA
Introduction
------------
It is now possible to externally drive MAME via LUA scripts. This feature initially appeared in version 0.148, when a minimal
``luaengine`` was implemented. Nowadays, the LUA interface is rich enough to let you inspect and manipulate devices state, access CPU
registers, read and write memory, and draw a custom HUD on screen.
It is now possible to externally drive MAME via Lua scripts. This feature
initially appeared in version 0.148, when a minimal Lua engine was implemented.
Today, the Lua interface is rich enough to let you inspect and manipulate
devices’ state, access CPU registers, read and write memory, and draw a custom
HUD on screen.
Internally, MAME makes extensive use of ``luabridge`` to implement this feature: the idea is to transparently expose as many of the useful internals as possible.
Internally, MAME makes extensive use of `Sol3 <https://github.com/ThePhD/sol2>`_
to implement this feature. The idea is to transparently expose as many of the
useful internals as possible.
Finally, a warning: The LUA API is not yet declared stable and may suddenly change without prior notice. However, we expose methods to let you know at runtime which API version you are running against, and you can introspect most of the objects at runtime.
Finally, a warning: the Lua API is not yet declared stable and may suddenly
change without prior notice. However, we expose methods to let you know at
runtime which API version you are running against, and most of the objects
support runtime you can introspection.
Features
--------
The API is not yet complete, but this is a partial list of capabilities currently available to LUA scripts:
The API is not yet complete, but this is a partial list of capabilities
currently available to Lua scripts:
- machine metadata (app version, current rom, rom details)
- machine metadata (app version, current emulated system, ROM details)
- machine control (starting, pausing, resetting, stopping)
- machine hooks (on frame painting and on user events)
- devices introspection (device tree listing, memory and register
enumeration)
- screens introspection (screens listing, screen details, frames
counting)
- device introspection (device tree listing, memory and register enumeration)
- screen introspection (screens listing, screen details, frame counting)
- screen HUD drawing (text, lines, boxes on multiple screens)
- memory read/write (8/16/32/64 bits, signed and unsigned)
- registers and states control (states enumeration, get and set)
- register and state control (state enumeration, get and set)
Usage
-----
MAME supports external scripting via LUA (>= 5.3) scripts, either written on the interactive console or loaded as a file. To reach the
console, just run MAME with **-console** and you will be greeted by a naked ``>`` prompt where you can input your script.
MAME supports external scripting via Lua (>= 5.3) scripts, either written on the
interactive console or loaded as a file. To reach the console, enable the
console plugin (e.g. run MAME with ``-plugin console``) and you will be greeted
by a ``[MAME]>`` prompt where you can enter your script.
To load a whole script at once, store it in a plain text file and pass it via **-autoboot_script**. Please note that script loading may be delayed (few seconds by default), but you can override the default with the **-autoboot_delay** argument.
To load a whole script at once, store it in a plain text file and pass it using
``-autoboot_script``. Please note that script loading may be delayed (a few
seconds by default), but you can override the default with the
``-autoboot_delay`` option.
To control the execution of your code, you can use a loop-based or an event-based approach. The former is not encouraged as it is
resource-intensive and makes control flow unnecessarily complex. Instead, we suggest to register custom hooks to be invoked on specific
events (eg. at each frame rendering).
To control the execution of your code, you can use a loop-based or event-based
approach. The former is not encouraged as it is resource-intensive and makes
control flow unnecessarily complex. Instead, we suggest to register custom
hooks to be invoked on specific events (e.g. at each frame rendering).
Walkthrough
-----------
@ -48,12 +60,18 @@ Let's first run MAME in a terminal to reach the LUA console:
::
$ mame -console YOUR_ROM
_/ _/ _/_/ _/ _/ _/_/_/_/
_/_/ _/_/ _/ _/ _/_/ _/_/ _/
_/ _/ _/ _/_/_/_/ _/ _/ _/ _/_/_/
_/ _/ _/ _/ _/ _/ _/
_/ _/ _/ _/ _/ _/ _/_/_/_/
mame v0.217
/| /| /| /| /| _______
/ | / | / | / | / | / /
/ |/ | / | / |/ | / ____/
/ | / | / | / /_
/ |/ | / |/ __/
/ /| /| /| |/ /| /| /____
/ / | / | / | / | / | /
/ _/ |/ / / |___/ |/ /_______/
/ /
/ _/
mame 0.226
Copyright (C) Nicola Salmoria and the MAME team
Lua 5.3
@ -68,35 +86,38 @@ At this point, your game is probably running in demo mode, let's pause it:
[MAME]> emu.pause()
[MAME]>
Even without textual feedback on the console, you'll notice the game is
now paused. In general, commands are quiet and only print back error
messages.
Even without textual feedback on the console, you'll notice the game is now
paused. In general, commands are quiet and only print back error messages.
You can check at runtime which version of MAME you are running, with:
::
[MAME]> print(emu.app_name() .. " " .. emu.app_version())
mame 0.217
mame 0.226
We now start exploring screen related methods. First, let's enumerate available screens:
We now start exploring screen related methods. First, let's enumerate available
screens:
::
[MAME]> for i,v in pairs(manager:machine().screens) do print(i) end
[MAME]> for tag, screen in pairs(manager:machine().screens) do print(tag) end
:screen
**manager:machine()** is the root object of your currently running machine: we will be using this often. **screens** is a table with all
available screens; most machines only have one main screen. In our case, the main and only screen is tagged as **:screen**, and we can further inspect it:
``manager:machine()`` is the root object of your currently running machine: we
will be using this often. ``screens`` is a table with all available screens;
most machines only have one main screen. In our case, the main and only screen
is tagged as ``:screen``, and we can further inspect it:
::
[MAME]> -- let's define a shorthand for the main screen
[MAME]> -- keep a reference to the main screen in a variable
[MAME]> s = manager:machine().screens[":screen"]
[MAME]> print(s:width() .. "x" .. s:height())
320x224
We have several methods to draw on the screen a HUD composed of lines, boxes and text:
We have several methods to draw a HUD on the screen composed of lines, boxes and
text:
::
@ -108,19 +129,22 @@ We have several methods to draw on the screen a HUD composed of lines, boxes and
[MAME]>> end
[MAME]> draw_hud();
This will draw some useless art on the screen. However, when unpausing the game, your HUD needs to be refreshed otherwise it will just disappear. In order to do this, you have to register your hook to be called on every frame repaint:
This will draw some useless art on the screen. However, when resuming the game,
your HUD needs to be refreshed otherwise it will just disappear. In order to do
this, you have to register your hook to be called on every frame repaint:
::
[MAME]> emu.register_frame_done(draw_hud, "frame")
All colors are expected in ARGB format (32b unsigned), while screen origin (0,0) normally corresponds to the top-left corner.
All colors are specified in ARGB format (eight bits per channel), while screen
origin (0,0) normally corresponds to the top-left corner.
Similarly to screens, you can inspect all the devices attached to a machine:
::
[MAME]> for k,v in pairs(manager:machine().devices) do print(k) end
[MAME]> for tag, device in pairs(manager:machine().devices) do print(tag) end
:audiocpu
:maincpu
:saveram
@ -134,7 +158,7 @@ On some of them, you can also inspect and manipulate memory and state:
[MAME]> cpu = manager:machine().devices[":maincpu"]
[MAME]> -- enumerate, read and write state registers
[MAME]> for k,v in pairs(cpu.state) do print(k) end
[MAME]> for k, v in pairs(cpu.state) do print(k) end
D5
SP
A4
@ -151,8 +175,8 @@ On some of them, you can also inspect and manipulate memory and state:
::
[MAME]> -- inspect memory
[MAME]> for k,v in pairs(cpu.spaces) do print(k) end
[MAME]> for name, space in pairs(cpu.spaces) do print(name) end
program
[MAME]> mem = cpu.spaces["program"]
[MAME]> print(mem:read_i8(0xC000))
[MAME]> print(mem:read_i8(0xc000))
41

26
docs/source/techspecs/memory.rst
View File

@ -71,7 +71,7 @@ Views are a way to multiplex different submaps over a memory range
with fast switching. It is to be used when multiple devices map at
the same addresses and are switched in externally. They must be
created as an object of the device and then setup either statically in
a memory map or dynamically through install_* calls.
a memory map or dynamically through ``install_*`` calls.
Switchable submaps, aka variants, are named through an integer. An
internal indirection through a map ensures that any integer value can
@ -593,29 +593,29 @@ parameter is that trigger width (would be 16 in the 68000 case).
.. code-block:: C++
map(start, end).view(m_view);
m_view[0](start1, end1).[...];
map(start, end).view(m_view);
m_view[0](start1, end1).[...];
A view is setup in a address map with the view method. The only
qualifier accepted is mirror. The "disabled" version of the view will
qualifier accepted is mirror. The “disabled” version of the view will
include what was in the range prior to the view setup.
The different variants are setup by indexing the view with the variant
number and setting up an entry in the usual way. The entries within a
variant must of course stay within the range. There are no other
additional constraints. The contents of a variant, by default, are
what was there before, e.g. the contents of the disabled view, and
then setting it up allows to override part or all of it.
what was there before, i.e. the contents of the disabled view, and
setting it up allows part or all of it to be overridden.
Variants can only be setup once the view itself has been setup with
the ``view`` method.
A view can only be put in one address map and in only one position.
If multiple views have identical or similar contents remember that
If multiple views have identical or similar contents, remember that
setting up a map is nothing more than a method call, and creating a
second method to setup a view is perfectly reasonable. A view is of
type **memory_view** and an indexed entry (e.g. a variant to setup) is
of type **memory_view::memory_view_entry &**.
type ``memory_view`` and an indexed entry (e.g. a variant to setup) is
of type ``memory_view::memory_view_entry &``.
A view can be installed in another view, but don’t forget that a view
can be installed only once. A view can also be part of “what was there
@ -787,8 +787,8 @@ Install a device address with an address map in a space. The
Installs a view in a space. This can be only done once and in only
one space, and the view must not have been setup through the address
map API before. Once the view is installed variants can be selected
through indexation to call a dynamic mapping method on it.
map API before. Once the view is installed, variants can be selected
by indexing to call a dynamic mapping method on it.
A view can be installed into a variant of another view without issues
with the only usual constraint of single installation.
A view can be installed into a variant of another view without issues,
with only the usual constraint of single installation.

8
src/frontend/mame/luaengine_render.cpp
View File

@ -426,7 +426,7 @@ void lua_engine::initialize_render()
i.set_element_state_callback(layout_view::item::state_delegate(
[this, cbfunc = cb.as<sol::protected_function>()] () -> int
{
sol::optional<int> result(invoke(cbfunc));
auto result(invoke(cbfunc).get<sol::optional<int> >());
if (result)
{
return result.value();
@ -455,7 +455,7 @@ void lua_engine::initialize_render()
i.set_animation_state_callback(layout_view::item::state_delegate(
[this, cbfunc = cb.as<sol::protected_function>()] () -> int
{
sol::optional<int> result(invoke(cbfunc));
auto result(invoke(cbfunc).get<sol::optional<int> >());
if (result)
{
return result.value();
@ -484,7 +484,7 @@ void lua_engine::initialize_render()
i.set_bounds_callback(layout_view::item::bounds_delegate(
[this, cbfunc = cb.as<sol::protected_function>()] (render_bounds &b)
{
sol::optional<render_bounds> result(invoke(cbfunc));
auto result(invoke(cbfunc).get<sol::optional<render_bounds> >());
if (result)
{
b = result.value();
@ -513,7 +513,7 @@ void lua_engine::initialize_render()
i.set_color_callback(layout_view::item::color_delegate(
[this, cbfunc = cb.as<sol::protected_function>()] (render_color &c)
{
sol::optional<render_color> result(invoke(cbfunc));
auto result(invoke(cbfunc).get<sol::optional<render_color> >());
if (result)
{
c = result.value();

2
src/mame/layout/mephisto_alm32.lay
View File

@ -33,7 +33,7 @@ license:CC0
<element name="text_h"> <rect><color red="0.56" green="0.33" blue="0.12" /></rect> <text string="H"><color red="0.87" green="0.87" blue="0.84" /></text> </element>
<element name="piece" defstate="0">
<text string=" "><bounds x="0" y="0" width="1" height="1" /></text>
<rect><color alpha="0" /></rect> <!-- force unit square bounds -->
<image file="chess/wp.png" state="1"/>
<image file="chess/wn.png" state="2"/>