Using Wiimote as a lightgun in MAME

Last time I wrote about how to get Wiimote to work as a mouse pointer in X. After that, I started to wonder if I could also use the Wiimote as a light gun in emulators, especially in MAME. MAME has some nice arcade shooters, like Time crisis, which would be much more fun with a proper pointer.

It should be quite simple, since MAME supports mouse as a light gun out of the box. Or so I thought. It turns out, it isn't so simple after all. I found a blog post which explained how to do it, but I couldn't get it to work.

First, I use autodetection in X.org, so I don't have xorg.conf. Anyways, since I already got X to detect the wiimote, I didn't think it would be a problem.
Second, even though e.g. jstest-gtk displayed the joystick, I couldn't get MAME to see it. No joysticks no matter what I tried. Also as a mouse the Wiimote acted weird. In desktop all was good, but in MAME cursor just jiggled in bottom right corner.

Anyways, after 3 evenings of trying I got it to work. Here's how it went:

First I connected the wiimote:
$ sudo wminput -c ir_ptr A4:C1:E2:C4:DB:4F
Put Wiimote in discoverable mode now (press 1+2)...
Ready.

Even though the jstest-gtk and sdl-jstest both displayed the wiimote as joystick and operated properly, the sdl2-jstest did not work. I assume MAME uses sdl2, so that explais why MAME did not see the Wiimote either.
$ sdl2-jstest --list
No joysticks were found

Then I decided to try different approach. I added my user to the "input" group, so that it can read /dev/input/eventXX which is where the Wiimote data comes from:
$ sudo usermod -G input [user]

After that I used evtest to check that the Wiimote really works, and what the event device number is:
$ evtest
No device specified, trying to scan all of /dev/input/event*
Not running as root, no devices may be available.
Available devices:
...
/dev/input/event14:     Nintendo Wiimote
Select the device event number [0-14]: 14
Input driver version is 1.0.1
Input device ID: bus 0x5 vendor 0x1 product 0x1 version 0x4
Input device name: "Nintendo Wiimote"
...

I entered 14 to the prompt (the number after the Wiimote event), and checked that events are reported when pointing the wiimote to a candle and moving it around. The events look like random blocks in the terminal.

After verifying what the event device is (in this case /dev/input/event14) , I forced SDL to use that device as the joystick device with an environmental variable, and behold, the Wiimote was detected as a joystick:
$ SDL_JOYSTICK_DEVICE=/dev/input/event14 sdl2-jstest --list
Found 1 joystick(s)

Joystick Name:     'Nintendo Wiimote'
...

And also testing it with the sdl2-jstest now worked properly. Great!
$ SDL_JOYSTICK_DEVICE=/dev/input/event14 sdl2-jstest --test 0

Now it was time to test with MAME. But first I wanted to disable the mouse operation of Wiimote so that it would not interfere with the joystick operation. I did this by finding the Wiimote device id with xinput, and then disabling that device:
$ xinput list
| Virtual core pointer             id=2    [master pointer  (3)]
|   ↳ Virtual core XTEST pointer   id=4    [slave  pointer  (2)]
|   ↳ Nintendo Wiimote             id=13   [slave  pointer  (2)]
| Virtual core keyboard            id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard  id=5    [slave  keyboard (3)]

$ xinput disable 13

After that the Wiimote did not move the mouse cursor anymore. Then I tried running MAME with these settings. I used -verbose mode to get debug info and piped it to less to be able to inspect the log. Now the Wiimote was dispalyed in the "Initializing Joysticks" portion.
$ SDL_JOYSTICK_DEVICE=/dev/input/event14 mame -verbose -sr 11025 timecrs2v2b | less

From the MAME menu (with TAB key) I could go to input and lightgun settings and set the lightgun 1 analog X and Y properly by moving the wiimote. The setting indicated something like JS1 axis 0 and JS 1 axis 1 if I remember correctly. The Wiimote worked properly as a lightgun!

I assume the problems come to the fact that the Wiimote operates as mouse and joystick simultaneously, why SDL does not really know which it is. That's why the device name has to be told explicitly. I also wonder if pointing it to /dev/input/js0 also, but I didn't test that yet.

For reference, here is the relevant parts from my ~/.mame/mame.ini to set the joystick to emulate lightgun:
# CORE INPUT OPTIONS
coin_lockout              1
ctrlr
mouse                     1
joystick                  1
lightgun                  1
multikeyboard             0
multimouse                0
steadykey                 0
offscreen_reload          1
joystick_map              auto
joystick_deadzone         0
joystick_saturation       0.85
natural                   0
joystick_contradictory    0
coin_impulse              0

# CORE INPUT AUTOMATIC ENABLE OPTIONS
paddle_device             joystick
adstick_device            keyboard
pedal_device              keyboard
dial_device               keyboard
trackball_device          keyboard
lightgun_device           joystick
positional_device         keyboard
mouse_device              mouse

And after storing the settings in MAME ingame menu, the following config in ~/.mame/cfg/timecris.cfg:
  <input>
    <port tag=":LIGHTX" type="P1_LIGHTGUN_X" mask="4095" defvalue="381">
      <newseq type="standard">
        JOYCODE_1_XAXIS
      </newseq>
    </port>
    <port tag=":LIGHTY" type="P1_LIGHTGUN_Y" mask="4095" defvalue="163">
      <newseq type="standard">
        JOYCODE_1_YAXIS
      </newseq>
    </port>
    <port tag=":MCUP5A" type="P1_BUTTON1" mask="16" defvalue="16">
      <newseq type="standard">
        JOYCODE_1_BUTTON2
      </newseq>
    </port>
    <port tag=":MCUP5A" type="P1_BUTTON2" mask="32" defvalue="32">
      <newseq type="standard">
        JOYCODE_1_BUTTON1
       </newseq>
    </port>
  </input>

Hopefully this will help someone to get the Wiimote to work in MAME. I also got the wiimote to work as a NES zapper in Mednafen, but I will write about it later.

Using Wiimote as mouse

I have wanted to use my Wiimotes with my HTPC since they would be great for things like point-and-shoot games etc. Maybe for media center too, but I haven't tried that yet.

Anyways, there are multiple tutorials on the net for getting wiimote to work, like CWiiD tutorial on Ubuntu wiki or XWiimote tutorial on Arch wiki.

Basically, this is how I understood, CWiiD is the older driver which is no longer developed and XWiimote is the newer one which behaves better.

XWiimote has driver for xorg and you pair the Wiimote just like any other bluetooth device. So it should be the method of choice. However, it does not yet support the IR pointer which I want to use. So until that it's a no-go.

CWiiD requires an user-space application which handles the Wiimote communication, and an evdev driver (some generic driver I think) communicates with xorg. CWiiD has IR-pointer support, and after few days of messing around, I got it to work.

First, I installed the necessary packages: bluetooth which installed bluez and wminput. Those installed all other libraries etc that were needed.

Then running wminput -c ir_ptr -w and pressing 1+2 on the Wiimote connected the mote and everything worked, except for the IR pointer. After reading xorg.log and browsing around the net I found the solution.

Problem is that the driver reports both relative and absolute movement, and ir pointer uses absolute which was discarded for some reason. Also, as the driver is loaded runtime using udev and everything, normal configs added to xorg.conf do not work. I worked around this by creating a new input class config for evdev; /usr/share/X11/xorg.conf.d/61-evdev-wiimote.conf which contains following:

Section "InputClass"
 Identifier "Nintendo Wiimote"
 MatchProduct "Nintendo Wiimote"
 MatchDevicePath "/dev/input/event*"
 Driver  "evdev"
 Option  "IgnoreAbsoluteAxes" "false"
 Option  "IgnoreRelativeAxes" "true"
EndSection

This forces xorg to use the reported absolute pointer location (IR pointer) instead of relative location (acceleration sensors etc), so now the pointer works. Only missing is a proper IR source, but a flashlight works fine until then.

Also one should note that the ir_ptr config is located in /etc/cwiid/wminput/ and from there the button and axis mappings can be changed.

Hopefully this helps others too, it took quite a while to figure that input class thing out.

Running Windows games in MythTV

Second post coming, after a while! Nice.

This time it's about how to properly play Windows games under MythTV and wine. Or MythGame to be precise, but it's part of the system, so...

On the MythGame wiki page there was nothing about wine, but after reading the other topics and experimenting a bit, I ended up with following system:

• I created a ~/Windows/ directory, and configured wine to use it as a D: drive. I will install all my Windows games there.
• All launchers will be stored in a new directory, ~/Windows/conf
• MythGame launcher for wine looks like this:
  

  - Player Name: Windows
  - Type: Other
  - Command: sh %s
  - ROM path: ~/Windows/conf
  - Working dir:
  - Extensions: sh
  - Uncheck the box about multiple ROMs

In the start, all launchers were just simple cd <gamedir>; wine <game.exe>, but I ended up with something better:

Often my windows games crashed, leaving the MythTV front-end broken, or had some problems with colors or resolutions. I crawled the web about launching another X session for wine games, because apparently there would be benefits:

• If a game crashes, it doesn't screw up the front-end
• Colors and resolution can be set independently of the front-end
• No other programs (opengl?) running on the same X server -> better performance
• The "Virtual desktop" in winecfg can be used (if game won't work without it) and it can be fullscreen, or if not, there is nothing on the backround anyways!

Of course it's not that easy. For some reason, launching X with only wine as a client didn't work, the new server just didn't work. But after few days of trying, I got it to work using a shell as the client.

At the same time, I figured I could use fuseiso to mount cd images automatically to ~/Windows/cdrom, which was configured as a cdrom drive in wine. This way: no hand mounting or inserting cds!

So here's an example of a working sh file to be put into ~/Windows/conf. It mounts the cd, set's resolution and launches the game. When the game ends, it
returns automatically to front-end! Neat!

#!/bin/sh

# Use FUSE to mount the cd image
fuseiso ~/Windows/Game_CD.iso ~/Windows/cdrom

# Launch new X server, with retro style (striped background, optional)
# and closing after the game is finished
# If not using NVidia gfx card, remove the & nvidia-settings ...
# And if you need to change color depth, use something like this:
# X :3 -retro -ac -terminate -depth 16
X :3 -retro -ac -terminate & nvidia-settings --load-config-only

# Forces the system to have a break for 2 seconds, X doesn't launch instantly
sleep 2

# Set correct resolution for this game, then
# launch the game on the new X display
cd ~/Windows/Game_dir/
DISPLAY=:3 WINEDEBUG=-all xterm -e "xrandr -s 800x600 && wine Game.exe"

# Unmount cdrom when done
fusermount -u ~/Windows/cdrom

Hopefully this helps others too, I think this is the only way to properly run Windows games (and why not other games too?) under Linux!