Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
libretro access to Lua #82
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.
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 .
and it will excecute your script.
you can alternatively load an cmd file (text file with cmd extension) that contain the command line.
this is my test.lua
and here is the result
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.
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 ***@***.***> 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 <#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 <#82 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAVOnMoM_ugk7fxvmOYC04tqUpklI5aeks5vcQ2rgaJpZM4Xx6d1> .
Arguments against this:
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.
This is not what I'm looking for.
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).
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)
It works fine without
The same command line works on my host MAME installation (including
"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.
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.
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 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
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.
For the console that appear to be disable...
mame libretro is one of the most hard core to configure correctly.
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"
then you can start to modify this files to fit your nedd.
if you did the things correctly, plugins should works fine then.
"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 ...
in fact the only PR that i will not agree with , will be PR that badly tweak the mame upstream files.
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.