libretro / mame

MAME - Multiple Arcade Machine Emulator
Other
63 stars 74 forks source link

Expose OutputManager through libretro API #99

Open JayFoxRox opened 5 years ago

JayFoxRox commented 5 years ago

I personally want to use libretro-mame for running games in my cabinets.

So I need the ability to read data from the OutputManager and possibly from device memory (the current memory interface doesn't appear to be sophisticated enough).

Example: https://github.com/libretro/mame/blob/453dfe2a5c3c19d8cddb87fb4e31ce5f7c4af1d5/src/mame/machine/wpc_lamp.cpp#L71

I'm not sure if retroarch already has a suitable interface / callback.

Alternatively, this could be implemented by exposing #82 differently.

r-type commented 5 years ago

how does it works with upstream ?

I made change in src/osd/modules/lib/osdobj_common.cpp to enable output module for libretro.

diff --git a/src/osd/modules/lib/osdobj_common.cpp b/src/osd/modules/lib/osdobj_common.cpp
index 621c22f0bc..b7f6bd6567 100644
--- a/src/osd/modules/lib/osdobj_common.cpp
+++ b/src/osd/modules/lib/osdobj_common.cpp
@@ -299,9 +299,10 @@ void osd_common_t::register_options()
        REGISTER_MODULE(m_mod_man, JOYSTICK_NONE);

        REGISTER_MODULE(m_mod_man, OUTPUT_NONE);
-#ifndef __LIBRETRO__
+//#ifndef __LIBRETRO__
        REGISTER_MODULE(m_mod_man, OUTPUT_CONSOLE);
        REGISTER_MODULE(m_mod_man, OUTPUT_NETWORK);
+#ifndef __LIBRETRO__
        REGISTER_MODULE(m_mod_man, OUTPUT_WIN32);
 #else
        //FIXME LIBRETRO OUTPUT

then i tested with

retroarch -v -L  mametiny_libretro.so "mame wrally -rp /mame/roms -output network"

and here is what i get

nc localhost 8000
mame_start = wrally
mame_stop = 1
JayFoxRox commented 5 years ago

I usually use this interface through LUA, like this:

o = manager:machine():outputs()
print(o:get_value("l:foobar"))

The output modules you suggest send a "Key = Value" pair whenever an output changes state (say.. a pin for an LED or motor on the cabinet). This feature isn't widely supported in MAME yet, but I'll probably work on it in the future.

I'm usually reserving the console (stdin / stdout) for the LUA console (which is disabled in libretro in the nightly builds?). Mixing the output console and LUA console would make parsing stdout much harder. The LUA console is also more useful than the output console because LUA can also access outputs (by polling or with a frame callback), but also control manager:machine():ioport().ports to set all switches on the machine. Hence I also referred to the LUA discussion: if I had control of LUA I could manually access OutputManager. Although the drawback is that this would be unportable to other cores.

I'd rather avoid opening a network socket, especially if communication is meant to be exclusively between the libretro core and my custom frontend. It's also unportable to other cores.


Ideal solution

Ideally libretro would expose an output callback, similar to the existing input callbacks. There is some related work on this with RETRO_ENVIRONMENT_GET_LED_INTERFACE (which is way too limited in my opinion). The benefit of having a standardized output callback would be that other cores could also benefit.


Background

As it stands I'm using MAME instead of libretro. I launch MAME with -console as a child-process and then communicate with it through stdin / stdout by injecting LUA commands. This has several drawbacks, such as not having audio and direct framebuffer access. Performance through that stream interface is also quite slow and fragile.

I'd like to migrate to libretro and handling communication through memory buffers and callbacks. With the possible option to also support non-MAME libretro cores with few code changes. However, this isn't currently possible, as I have no way to observe the output states (which can convey critical game information, especially for MECHANICAL devices).

There might also be an issue where only io-ports which have keys mapped to them are exposed in libretro (which is an issue for devices exposing keyboards or >50 gameplay switches, like Pinball machines) - so I'd still need LUA / further improvements to the input callbacks in this core.