scripting dolphin

<phire> I've actually been looking into scripting
<Warepire> I have considered some approaches to a "bring your own scripting language" approach, but haven't had time to draft it.
<phire> yeah, I'm halfway through drafting mine
<Warepire> My idea was to extend the memory watcher interface into a control socket.
<phire> so RPC?
<Warepire> And then provide example bindings for a language, e.g. python.
<Warepire> Pretty much
<Warepire> But, that's as far as my idea is defined, not a single line of code exists yet
<phire> jroweboy has a prototype of such an idea: https://github.com/jroweboy/emurpc/
<feos> does that allows to use an interactive scripting console?
<Warepire> In my idea you'd use the one that comes with the scripting language.
<phire> you can have whatever you want at the other side of the socket
<Warepire> Yeah ^
<phire> or, if you really want an intergrated console into dolphin, you can make a two way connection back
<phire> so, my idea is a bit more OTT
<phire> for context, scripting preformance is an issue for me. Because I want the scripting interface to be powerfull enough to do shader replacement or geometery replacement.
<feos> how fast would this approach be? when people get scripting support in emulators, they go nuts with it and uncover bottlenecks
<feos> heh, you've read my mind
<phire> So, I want a plugin api, where plugins are loaded via DLLs
<phire> and the scripting api would be a subset of the c ABI
<phire> So, if you really need preformance. you write a plugin in c.
<phire> But... The most common type of plugin would be scripting host plugins
<delroth> maybe we can even allow registering plugins for mmio ranges or IOS devices! then you can write your own implementation of GX or WiimoteEmu or DiscIO in a plugin!
<delroth>  /me hides
<phire> you would have one for javascript, one for python, one for lua
<phire> delroth, I'll add it to the list
<feos> https://pastebin.com/wRPpesBj
<phire> And users would be albe to use whatever scripting interface they want
<feos> to emphasize the most important lines from there,
<feos> <Masterjun> adelikat_: https://twitter.com/Masterjun3/status/1191520618841362432
<feos> <Masterjun> that twitter link is Lua, fully emulating a 65816 cpu, at 250 fps
<booto> haha, also include on the list the ability to trigger scripting stuff on breakpoints :P
<phire> booto: yeah
<delroth> there's basically 3 main use cases: TAS, modding, and general automation
<delroth> figuring an API that works well for all 3 is tricky
<delroth> for automation a control socket API is enough, but likely not for the other two
<feos> well of course writing pluginc in C makes them unbeatable in terms of speed
<delroth> might barely work for TAS
<feos> if you can register callbacks on some variety of internal events, tas would be fine
<delroth> for modding an extra constraint is you probably want some level of safety, e.g. not allowing people to trivially write malware through such a plug-in API
<phire> ugh... that's the hard one
<delroth> because otherwise you're basically screwed if you also want to provide a distribution platform
<phire> in my design, the scripting host dlls would be allowed to state they are sandboxed (or provide a sandboxed mode). But c dlls could never be sandboxed
<delroth> something something WASM also
<delroth> might be a solution
<delroth> not completely sure to what problem though
<phire> sandboxing, maybe
<phire> I mean, if you have a v8 plugin, it comes with WASM and you can use it to execute compiled code
<delroth> I think scripting hosts could be somehow built and distributed by us
<delroth> just separately built to avoid bulking the regular downloads
<phire> yeah, potentially downloaded an installed automatically
<feos> so with this approach, a plugin for lua scripting would accept lua code, turn it into C API calls (or sockets) and send to dolphin?
<phire> yes
<feos> would they be strictly limited to just C, or any language that can work with C API?
<phire> pretty much any language has support for calling c APIs
<phire> and almost every compiled language supports being compiled to a .dll that can be loaded and comunicated with via a C API
<feos> good
<feos> so what about registering callbacks in this scenario?
<phire> so sligthly more controversial in my design. It's entirely callback based
<feos> I mean I can have a lua function registered and called every frame?
<phire> there is no main loop
<phire> if your script wants to do anything useful, there is an init() callback that gets called on boot, and it has to register callbacks for any events it's interested in
<feos> alright
<phire> it might register for once a frame, at any point during the frame (based on timing)
<phire> or it might register for when a certan emulated function is called
<feos> so the internal scripting api should provide enough places you'd want to hook into
<phire> or for a render compele interrupt
<phire> yeah, like I said, I'm designing this with modding in mind
<feos> nice
<phire> because I see modding as the most demanding workload
<feos> this approach is properly mature compared to "support lua"
<feos> we're considering taking it in bizhawk
<feos> it already has api for compiled plugins
<phire> oh, I should check that out
<feos> well plugins are meant to be c#
<feos> that allows exposing entire classes
<Bh44L> you can still do that in lua with metatables, so not really an argument :D
<feos> except that'd be "just lua"
<feos> while plugin api allows anything
<phire> ah, so limiting to a single language (of c#)
<phire> the downside of my planned approach, is the raw c api might look a bit janky.
<phire> because it needs to support everything
<feos> c# makes it harder for plugins to talk to *anything*, so the original intent was just having plugins as ends
<feos> when porting mame to bizhawk, I took an interesting approach. I implemented basic c api to send lua code, and then mame's internal luaengine interprets it and reacts, sending stuff back through c api
<phire> delroth: the other thing I was thinking about is making the scripting host dlls portable to any emulator (or other program) supporting the same base ABI
<feos> so I only need a string sender, and a few type returners
<phire> so if I can convince citra and other emualtors to support the same base ABI, then a scripting plugin for any given language only need to be written once
<feos> that's actually crazy!
<phire> the ABI would include a discovery endpoint, so the scripting plugin can ask whatever emulator it's plugged into "What types and methods do you support"
<phire> then it can automatically export them to it's scripting enviroment
<phire> Also means, dolphin wouldn't have to rebuild it's scripting host plugins every single time a new API is added or modified
<feos> what about emulators exposing unique things? plugins would have to be different even for the same master language
<phire> yes, but that's a given
<phire> it might be possible to write plugins that work in multiple emulators, also taking advantage of the discovery endpoint
<feos> right
<phire> I don't really want to force a "this is what your emulator API must look like"
<phire> maybe, I'll try to define a few base things, like "this is the memory reading endpoint that should be flexable enough for anything"
<feos> for sane memory reading you need to report regions to the user, then it can be made really handy
<phire> I guess allow that as part of the discovery api
<phire> this project has a few parts.
<feos> in hawk, since we emulate a ton of systems, we have getregions() iirc, that just prints them, same for getregisters()
<feos> and then you work with the region you want
<phire> 1. A c++ library for registering hooks, types and method exports, exporting them over c
<phire> 2. The actual plugin lifecycle
<phire> 3. The ABI, what types are we supporting
<phire> 4. The discovery API for comunicating those types to plugins
<phire> 5. The 3 base scripting plugins: Javascript, Python, Lua (Luajit?)
<phire> 6. The actual API for dolphin