Use dolphin's MemoryWatcher

[spxtr]

In dolphin-emu/dolphin#3403 and dolphin-emu/dolphin#3413 I added a little class that watches user-specified game memory locations and outputs changes to a unix socket. It checks for updates every 2 ms, so you'll still have plenty of time to think and send controller inputs in the 16 ms frame window. It's somewhat documented here. I'll add some documentation to the wiki, but here's a simple program to get started:

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/un.h>

int main(int argc, char *argv[])
{
    char *path = "/path/to/.dolphin-emu/MemoryWatcher/MemoryWatcher";

    int fd = socket(AF_UNIX, SOCK_DGRAM, 0);
    struct sockaddr_un addr;
    memset(&addr, 0, sizeof(addr));
    addr.sun_family = AF_UNIX;
    unlink(path);
    strncpy(addr.sun_path, path, sizeof(addr.sun_path) - 1);
    bind(fd, (struct sockaddr*) &addr, sizeof(addr))

    char buf[128];
    while (1)
    {
        struct sockaddr remaddr;
        socklen_t addr_len;
        recvfrom(fd, buf, sizeof(buf), 0, &remaddr, &addr_len);
        printf("%s", buf);
    }
    return 0;
}

[altf4]

Sweet! Thanks! I'll convert my I/O to that and see how it goes.

I haven't been measuring it empirically yet, but I don't think that I have been using up a significant portion of the 16ms decision time with AI cycles. So losing 2ms on polling shouldn't be an issue.

[spxtr]

As always, let me know about any issues here or on IRC :)

[altf4]

FYI: I'm still working on this, but initial results are that it works and should be fine. I'm hoping to push the change this weekend.

[spxtr]

Splendid :)

[altf4]

Added in 5eb963f

Seems to be working great! No more spin loops. Also no need to patch dolphin and recompile.

[spxtr]

Hooray!

[stephenjayakar]

Yo @spxtr, quick question. If I wanted this to work in windows, would I just have to adapt this code to use AF_INET instead of AF_UNIX? It would be a lot slower, so maybe I'll add an if statement that would check the environment and change socket type. There's no way to use this code on Windows otherwise, right?

[altf4]

@sajayakar56 Take a look at libmelee if you're thinking of making a Windows-compatible Smash-playing bot. It's not 100% there yet, but almost.

https://github.com/altf4/libmelee/

[spxtr]

Dolphin's side is hard-coded to only work on linux. I don't know how windows IPC works, but presumably the MemoryWatcher and Pipe controller will need a windows version. Feel free to make a PR for each and mention me on them. I added the pipe interface in dolphin-emu/dolphin#3170.

[altf4]

@spxtr Is correct. I just mean that libmelee contains all the bot-side stuff that you need in windows-compatible Python code. (Dolphin is still Linux-only in two key features)

[vladfi1]

@sajayakar56 There's a guy (jojorino) in the phillip discord server who's been working on Windows-compatible memory watcher/pipe input in Dolphin using zmq sockets over tcp.

[altf4]

Sounds cool. Buuuuut, swing that by some of the Dolphin devs if you haven't already. To make sure that's a design they'd be comfortable accepting a PR with.

[vladfi1]

Yeah it'll have to be a fork, as they vehemently shut down my zmq proposal a month a go. That was mostly due to them hating zmq, but also being generally against these "IPC hacks" and demanding that it be done properly via either an embedded scripting language or a proper dolphin library.

[altf4]

I think that maintaining a separate dolphin fork is not the right way. I would definitely prefer something that they would actually accept as a PR. That probably means direct windows ports for the Linux functionality, without using a 3rd party lib.

Also, I wonder what "a proper dolphin library" looks like?

[stephenjayakar]

Wow thanks for all the help guys! I've actually started developing my own lib using the existing AF_UNIX implementation, but I'll keep investigating! @altf4 it's impressive you wrote SmashBot in C++ but libmelee in python! I was looking for a comprehensive list of mem addresses; seem like you have it :)

Haha @spxtr didn't you code in the MemoryWatcher and the Pipe yourself :P

[stephenjayakar]

@vladfi1 did you use zmq for cross-language compatibility?

[spxtr]

Haha @spxtr didn't you code in the MemoryWatcher and the Pipe yourself :P

Yep, if you have any questions then feel free to open an issue in spxtr/p3 or altf4/libmelee and cc me.

[altf4]

@sajayakar56 Heh, yea it looks confusing, but TL;DR: SmashBot should have been Python all along. I'm in the middle of a Python-rewrite at the moment, in fact. Expect that soon. libmelee is basically all the non-SmashBot specific part of that code that anyone could adopt.