dockerized version - offer to help
I just thought about how to make drc-sim easily used on other OSes. It occurred to me that one could make a docker image of the software. This could cut down on questions regarding two common problems: questions that might arise from people having trouble installing all the dependencies on their linux machine, and being able to use drc-sim on windows/mac-os machines (dockers are like small virtual machines).
I am still waiting for my power supply to come in for my cheap used wii u (it came with no peripherals!), but once I have it I can try to make a docker version of drc-sim.
I am not familiar with Docker, so I cannot comment on issues that might arise from using drc-sim in that environment.
I will say that drc-sim running on OS X and Windows natively is likely possible. The main issue would be compiling wpa_suppplicant for them.
I will leave the issue open. Let me know if you come across any difficulties.
Windows 10 Host
Result: Not Compatible
Reason: The hosts' interfaces are not accessible from the Docker image even with privileged and net=host flags.
thanks for this update, that's interesting that it doesn't work "out of the box" with regard to the interfaces, so I guess it is not passing information about the host interfaces to the docker image. Hmm, I will look into this some more.
I have been thinking about this. One option is maybe autoloading drc-sim on a small/light ubuntu USB booter image - it might be the solution for people who don't know linux. Another alternative option is a Virtual Box image which might be easier to configure compared to docker.
I myself run it in a VM without any issues. An image could be distributed but the drivers for the wifi adapter would need to be installed. A frozen Python virtualenv wrapped in a Debian installer seems like a way to avoid a majority of the CLI commands during install.
I attempted to compile wpa_supplicant for Windows, but the wireless API changed in Vista and later from Wireless Zero Configuration to WLAN AutoConfig.
I tested Docker running on Debian 8 there is still the issue of the drivers needing to be installed. I am not sure the best way to get around this other than adding driver package installations to the dockerfile.
Edit: It was not a driver issue. The container was not running with the privileged flag.
I have been considering an install script that would take care of dependencies, create a virtualenv and install a script that would launch the backend in that virtualenv. With the GUI implemented a .desktop shortcut would add it to the launcher for a fully GUI based launch and interaction.
There is now an install script.
The Docker script is working on Linux hosts and there is now documentation on the wiki. The Windows and OS X versions need testing. I do not have native installs of either for testing, so I am going to assume the are not working.
Nice! Thanks for making this! I am going to try the Docker script on Mac OSX and Windows. I will try to get back to you with my results.
I had a try with the docker image on MacOSX -the image installed with no issue. I ran the following command (tried both docker0 and eth0):
docker run -p=50000-50002 --net=host --privileged -v=drc:/root/.drc-sim/ drcsim/drcsim --verbose get_key docker0 1202
not sure yet if it is just a network/bridge assignment problem or if wpa_supplicant_drc doesn't like the host (MacOSX). My macbook air has a 802.11n 5GHz wifi adapter (I can see the WiiU SSID pop up in scanned networks on the MacOS listed Wi-Fi networks) so at least I can rule out network adapter compatibility.
I will try the docker image on Windows 10 tomorrow
The Docker solution will not work on macOS because --net=host does not work on macOS like you'd expect (see https://github.com/docker/for-mac/issues/68). I'm not sure about Windows.
I'm able to compile wpa_supplicant on macOS with a few config changes. drc-sim also runs fine once you get all of the dependencies. Unfortunately wpa_supplicant does not have drivers for the Apple80211 stack. They had experimental OS X drivers pre-2.0 (see https://android.googlesource.com/platform/external/wpa_supplicant_6/+/froyo/wpa_supplicant/src/drivers/driver_osx.m) but they removed them in version 2.
The Apple80211 framework appears to have changed since then. I wonder if we could get something running by updating the driver_osx.m code for the Apple80211 API changes and reintroducing it into wpa_supplicant.
Some research reveals:
- Apple80211 was a private framework that's now deprecated
- CoreWLAN replaced Apple80211 and is officially documented
Getting drc-sim to work natively on macOS may just be a matter of implementing driver_osx.m with CoreWLAN. I'd love to see that happen and it could be a fun little project if I get time.
thanks cafarm for explaining the problem with MacOSX docker.
I couldn't test Windows 10 with the docker since I only have 32-bit windows 10 (Docker needs 64-bit).
I'm trying now drc-sim installed on a Ubuntu virtualbox guest on my MacOSX machine host. I'm using a bridged network adaptor to my en0 on the mac (also tried NAT in the beginning, but that didn't work). In the ubuntu guest, ifconfig shows "enp0s3" as the network adapter (I was expecting eth0). Using the CLI I can't get the ubuntu guest to see the WiiU for syncing. I'm probably doing something wrong but not sure.
A bridged network adapter in a VM won't work either (see http://kb.parallels.com/en/123823). I think the only way to make it work in a VM is to use a wireless USB adapter. Unfortunately I don't have a USB adapter capable of 5Ghz 802.11n.
thanks a lot cafarm - that answered my question with the VM issues. I guess I can't piggyback on my own Mac's built-in WiFi . Although I remember roland mentioning he can use a linux virtual machine to run drc-sim (but in his case, linux guest, and linux host). Maybe he is using direct drivers in the vm though.
I do have a usb 5Ghz 802.11n adapter that I used successfully from my small linux pc with drc-sim. It doesn't seem to work with my Mac though.
The USB adapter will not work with the Docker VM either.
See boot2docker/boot2docker#1253
Although I remember roland mentioning he can use a linux virtual machine to run drc-sim (but in his case, linux guest, and linux host). Maybe he is using direct drivers in the vm though.
I have had success with a Windows host and Linux guest as well. Attaching the wireless adapter as a USB device to the VM and installing the drivers for it should be all that is required. From there, the install script and maybe Docker image should work.
I can confirm now that drc-sim works on VirtualBox with MacOS host (Macbook Air mid-2012) and Lubuntu guest. I also run the drc-sim-client in the Lubuntu guest.
I get more drc-sim-client 'socket closed' connection drops with this setup than I do with my actual linux box (atom 330 cpu) which also occassionally dropped the connection. Perhaps both setups are too underpowered for drc-sim.
In any case, it works!
Same. I got a USB adapter capable of 802.11n 5GHz and it works fine with a macOS host and Ubuntu VM.
Performance isn't stellar though. There's a good amount of lag and dropped frames. I suspect if we got things running completely native on macOS, that'd be an improvement.
Have you tried editing the server.config file in your ~/.drc-sim folder? I notice a little better performance when lowering the fps, and image quality (I don't care about the screen too much). I also turn off the audio as well.
Nope. I really want full 480p with audio.
I doubt the Wii U gamepad is more powerful than my MacBook Pro 2011. It doesn't have to run a heavy OS and a VM and it might have hardware specifically for decoding H264 though? Or maybe it's the fact that drc-sim is written in python and drc-sim-client is written in Java? Curious if a C implementation would make much difference.
The server implementation in Python is slow. The speed was acceptable with Python 2, but the move to Python 3 slowed thing down even more. At the moment the server is using a very hacky way of getting a speed boost--I reduced the input updates to 5% (180 to 10 per second). I have not done any specific benchmarking, but the packet parsing makes up between 40 to 60 percent of the CPU load. I expect that would be reduced in a compiled language. The actual decoding is done in a C call via CFFI and the gamepad does use a hardware decoder.
I have taken a look at the CoreWLAN framework and it looks like it would be mostly straightforward in updating to it from the Apple80211 framework. I did try to compile with Apple80211 on macOS 10.12 but, as expected, its implementation has changed.