libretro access to Lua

[runvnc]

Would it be feasible to add some custom environment() call that somehow passes access to the Lua system from Mame over to the frontend? Maybe this is silly but would it be possible to actually just pass a lua_State *? Or alternatively just a way to read and write memory (through Lua) maybe with two different environment() calls or something. Or maybe there could be a sort of generic memory map that would be given to the frontend and then that would be implemented with the Lua stuff.

Is the Lua stuff tied in with the command line or interactive terminal and if so does it need to be disentangled or how might I access it in the libretro part of the code.

Thanks for any hints.

[r-type]

sorry i don't understand all your request , but yes lua is fonctionnal and you can pass lua script to this mame core, but you need to use command line .

like this

retroarch -v -L /somwhere/mame_libretro.so "mame atetris -autoboot_script /elswhere/test.lua -rp /rompath/roms"

and it will excecute your script.

you can alternatively load an cmd file (text file with cmd extension) that contain the command line.

[r-type]

this is my test.lua

s = manager:machine().screens[":screen"]
-- we define a HUD-drawing function, and then call it
function draw_hud()
s:draw_text(40, 40, "foo"); -- (x0, y0, msg)
s:draw_box(20, 20, 80, 80, 0, 0xff00ffff); -- (x0, y0, x1, y1, fill-color, line-color)
s:draw_line(20, 20, 80, 80, 0xff00ffff); -- (x0, y0, x1, y1, line-color)
end
draw_hud();

emu.register_frame_done(draw_hud, "frame")

and here is the result

https://docs.mamedev.org/techspecs/luaengine.html

[r-type]

anyways you can also use the -console argument like

retroarch -v -L mame_libretro.so "atetris -rp /somewhere/roms -verbose -console"

[JayFoxRox]

sorry i don't understand all your request , but yes lua is fonctionnal and you can pass lua script to this mame core, but you need to use command line .

I want to get access to OutputManager (see #99). I could do this myself, if I could inject LUA calls / functions at runtime, which would retrieve the result via libretro APIs. As it stands, I'd have to open a sidechannel, like a socket, from a LUA script injected through the CLI. This feels like a cumbersome and fragile hack.

So either libretro needs a new API for outputs to make stuff like LUA scripting redundant using its own features, or it should gain a more flexible core-specific API which can be tweaked to utilize all features of the core.

[runvnc]

I don't know if it's relevant to you but my project has a Lua interface for libretro get_memory_data. http://vintage simulator.com

On Sun, Mar 31, 2019, 12:34 PM Jannik Vogel notifications@github.com wrote:

sorry i don't understand all your request , but yes lua is fonctionnal and you can pass lua script to this mame core, but you need to use command line .

I want to get access to OutputManager (see #99 https://github.com/libretro/mame/issues/99). I could do this myself, if I could inject LUA calls / functions at runtime, which would retrieve the result via libretro APIs. As it stands, I'd have to open a sidechannel, like a socket, from a LUA script injected through the CLI. This feels like a cumbersome and fragile hack.

So either libretro needs a new API for outputs to make stuff like LUA scripting redundant using its own features, or it should gain a more flexible core-specific API which can be tweaked to utilize all features of the core.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/libretro/mame/issues/82#issuecomment-478373098, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVOnMoM_ugk7fxvmOYC04tqUpklI5aeks5vcQ2rgaJpZM4Xx6d1 .

[r-type]

Anyways, i think we can close this one, as lua is functional and you can access lua console using -console switch in libretro mame like in the upstream version.

[JayFoxRox]

Anyways, i think we can close this one

Arguments against this:

1. -console is currently disabled in official libretro builds (from https://buildbot.libretro.com/nightly/linux/x86_64/latest/)
2. The frontend might use stdin / stdout for other purposes
3. The frontend has no way to easily remote control the MAME core (extension of previous argument: there's no virtual stdin/stdout for communicating core)

lua is functional and you can access lua console using -console switch in libretro mame like in the upstream version.

The point of these kind of issues should be to expose these features through the libretro APIs (either new APIs or environments), so they can be used by frontends. If just enabling the LUA console was good enough one could also argue that providing audio and video through a MAME owned-window is equally fine - but that defeats the point of using libretro in the first place.

---

I don't know if it's relevant to you but my project has a Lua interface for libretro get_memory_data.

This is not what I'm looking for. I don't want to access memory directly (which would be a game specific hack), but stable interfaces for inputs and outputs (including LEDs / Motors / Framebuffers / Audio output samples / ...).

Ideally I want to have some form of libMAME with a sane interface, possibly shared by other non-MAME emulators (hence libretro sounds most suitable).

[r-type]

Arguments for

1. -console is not disable, if you dont know how to use/activate ask for help.

2. These core act for the most like upstream one. Lua access for these core is the same provide by upstream mame.so in the point of view of your issue title, the issue is close. So correct your title to reflect what are your asking. For the output modules we will try to add them in the next update.

3. The frontend issue or missing features have not to be handle by the core. Open issue on the frontend repo.

4. Lua works as it works with upstream, If you want more ask or implement them in upstream.

5. If your are not happy how this core works or is updated then go ahead, fork it and provide PR.

[JayFoxRox]

-console is not disable, if you dont know how to use/activate ask for help.

It appears to be (based on a hacked fork of this):

mame = core.EmulatedSystem("./mame_libretro.so")
print(mame.get_library_info())
cli = 'mame "%s" -rompath ~/.mame/roms -console' % game_name
mame.env_vars[b'mame_boot_from_cli'] = b'enabled'
mame.load_game_normal(path=cli, get_data_from_path=False)

Outputs:

{'api': 1, 'name': 'MAME', 'ver': '0.208', 'exts': 'chd|cmd|zip|7z'}
Ignoring MAME exception: Console plugin not found.

Console plugin not found.

It works fine without -console in the CLI string (but obviously the LUA console will be missing). This was tested on an official precompiled libretro MAME core that was downloaded 2 days ago from the provided link from my last post (Linux x64).

The same command line works on my host MAME installation (including -console) from arch linux repositories.

These core act for the most like upstream one. Lua access for these core is the same provide by upstream mame.so in the point of view of your issue title, the issue is close.

"libretro" in the name implies an access through the API. The first post explicitly refers to the API by speaking about a custom environment addition. It also explicitly discusses frontends access to the LUA API.

So correct your title to reflect what are your asking.

This is not my issue, but I'm just another stakeholder. I can't change the title - as explained, I also think the title and issue comment is very descriptive.

The frontend issue or missing features have not to be handle by the core. Open issue on the frontend repo.

This is not about the frontend (retroarch), but about issues with this particular core: LUA is MAME specific and could be exposed through core-specific extensions (which are handled by environment calls in libretro)

It could also be interpreted as an issue with the libretro API as a custom interface shouldn't be necessary if the API is powerful enough (see #99 for a specialization which avoids these core specific hacks).

Lua works as it works with upstream, If you want more ask or implement them in upstream.

LUA in the upstream works fine, but it's exposed through protocols or channels which are not available (console) or suitable for use in libretro (network). Yes, it remains usable by a human, but it's not usable for a programmable frontend without security risks or additional administrative actions.

I've explained this in my earlier post: If the metric is purely that something works, and not how it works, then libretro is entirely unnecessary. You could just package a bunch of emulators and ask frontends to exec each of the emus (but that wouldn't provide a stable interface for framebuffer, input and audio). The benefit of libretro is standardized APIs and access to emulation functions through a shared-object / DLL - and that means replacing the interface to subsystems (be it framebuffer, input, audio or incomplete stuff like output or scripting).

If your are not happy how this core works or is updated then go ahead, fork it and provide PR.

So far, there's too little guidance and design recommendations for a PR - these issue discussions are specifically to get design recommendations or discuss how things could be implemented.

I won't be spending hours of work and coordinating with other core maintainers how to do something if this is going to be rejected or insufficient after all the work is complete. So I'm obviously discussing this for the core I'm most interested in - and this is this discussion.

[r-type]

For the console that appear to be disable...

mame libretro is one of the most hard core to configure correctly. if you want plugins working you have to to some extra step ,and the lack of documentation make this task a little harder.

First you have to copy mot of the files provide by the mame binary release in a folder named "mame" inside your retroarch system directory. (this include ctrlr , hash ,ini,plugins ...)

then you can start to create an mame.ini ( using cmdline so you have to be sure that the retroarch-core-options.cfg have mame_boot_from_cli = "enabled" also it is a good thing to enable mame_read_config = "enabled" and mame_write_config = "enabled")

just launch retroarch -v -L mame_libretro.so "mame -cc" and it will create 3 files : mame.ini plugin.ini and ui.ini

then you can start to modify this files to fit your nedd. ex: enable the console plugins. change the path in the mame.ini when it is done , just drop this file in your retroarch_systemdir/mame/ini

if you did the things correctly, plugins should works fine then. (personally i use console and hiscore and they work fine)

"libretro" in the name implies an access through the API.

yes that true.

LUA in the upstream works fine, but it's exposed through protocols or channels which are not available (console) or suitable for use in libretro (network).

As said previously, my primary goal here is to tend to have a port that is the most functionnal possible (like the upstream one) , there are some feature that not working in this port (eg: i don't add here the debuger even if i have a functional imggui debuger port because it imply that i have to re-add libco for have a functional debuger build)

So for me if lua works like upstream my point of view is that lua is functional.

now if i understand well your goal , it's more an enhancment instead of a fix for an non functionnal issue.

So for me it's is out of my personal scope , i will not spend hour to accomplish this ... but that said it's not meaning that i'm against this, i just say that i will not work on this but if someone want and did a PR i will have no reason to be against.

in fact the only PR that i will not agree with , will be PR that badly tweak the mame upstream files. first because this will be not respectfull for the mamedev works and secondly because this will lead to something that will be not maintainable. But anyway , i'am just contributor here and maintainer of this core by force of circumstances. then if one day the admin here decides to take another direction I will not really have any weight to make them change their minds.

Now, for me, all changes/PR in the libretro/osd part are welcome, even more if they add feature and take benfit of the libretro API.