I will give this a shot later tonight…
I believe it just says Android under input drivers. I gotta udate though
I will give this a shot later tonight…
I believe it just says Android under input drivers. I gotta udate though
@thatman84 I’ve been getting the “Input Drivers” guide ready for more testing. Hopefully the android input driver will work for you and we can fill out that prat of the template: https://buildbot.libretro.com/docs/guides/input-drivers/
there is something i do not understand. under windows, im expecting the use of RETRO_DEVICE_POINTER gives you absolute coordinates. In the doc RAW driver supports absolute but its not moving the pointer (fceumm zapper mode), while dinput dont support absolute but here its able to use RETRO_DEVICE_POINTER.
I don’t understand either.
I’m going to suggest that for NES/Famicom light gun testing we use Chiller (USA) (Unl)
because it supports dual simultaneous light guns, unlike Duck Hunt.
I have just tested Chiller in FCEUmm and Nestopia. The windows raw
driver does not seem to be sending mouse input to either of those cores regardless of what kind of mouse device I use. Both cores do work as expected with the dinput
driver although as mentioned it only supports one mouse/light gun.
This seems like a bug, so I’ll write up an issue.
currently, fceumm is not set to have both ports use zapper since i never knew a game that uses it at the same time. lemme check out chiller later then and ill see if i can do something…
Thanks @wertz – I just posted an issue here: https://github.com/libretro/RetroArch/issues/5472
I hope that I was not premature in doing so
btw, in fceumm you can actually set zapper to use absolute or relative mode using core option. normal NES roms zapper should be in user 2, VS Unisystem roms zapper is in User 1
The way I understand @casdevel, once this work on the input drivers is complete it won’t be necessary to have things like core settings for relative vs. absolute. It should eventually ‘just work’
For now though, this is confusing
I have also discovered that the Windows sdl2
input driver works in Nestopia (no multi-mouse support though) but sdl2
does not work in FCEUmm. Hmm.
i think thats not possible. RETRO_DEVICE_POINTER gives absolute coordinates while other devices are relative,-based including LIGHTGUN.
I believe the new functionality interpolates the absolute coordinates into relative coordinates within the input driver before they are sent to the core. There is some discussion about it starting with this comment: https://github.com/libretro/RetroArch/issues/5215#issuecomment-328569999
I have not studied casdevel’s commits to see exactly what mechanism he is using to make this work though.
im not able to follow that since im mostly using linux now. so whats this about then? somehow it just switches to relative or absolute mode? i think each core have different approach if its using DEVICE_POINTER or DEVICE_MOUSE/LIGHTGUN
Ill try but im not very technical and time is short the next 2weeks.
Currently into hour 13 of a 8 hour day
i was thinking of how currently retro_device_xxx behaves now, wherein mouse/lightgun gives you value depending of how much you move the mouse, and pointer gives you coordinate based on -0x7fff to 0x7fff min-max for x/y coordinates.
Would someone be able to drop the quick steps in for setting up and testing dual mouse for PC
Hopefully it will help me and others get the tested
Configuring RetroArch for multi-mouse use
Input Drivers: As of September 2017, there are two RetroArch input drivers with support for multi-mouse: udev
and the Windows raw
driver. It’s possible that other drivers will support multi-mouse in the future, although for some input drivers it is inherently impossible due to their design.
Emulator core and game: The reference emulator and content for multi-mouse is MAME 2003 with Area 51 (area51.zip
and its corresponding CHD). If possible, test with this ‘known good’ combination before trying others.
Determining mice index numbers
--verbose --menu
so that you can see status messages. (If that’s not practical, folks can use trial and error to find the indexes.)[INFO] [udev] Adding device /dev/input/event11 as type ID_INPUT_KEYBOARD.
[INFO] [udev] Adding device /dev/input/event3 as type ID_INPUT_KEYBOARD.
[INFO] [udev] Adding device /dev/input/event12 as type ID_INPUT_MOUSE.
[INFO] [udev] Adding device /dev/input/js0 as type ID_INPUT_MOUSE.
[INFO] [udev] Adding device /dev/input/mouse1 as type ID_INPUT_MOUSE.
[INFO] [udev] Adding device /dev/input/event4 as type ID_INPUT_MOUSE.
[INFO] [udev] Adding device /dev/input/mouse0 as type ID_INPUT_MOUSE.
If you are using Windows raw, you are looking for something like this:
[INFO] [WINRAW]: Initializing input driver ...
[INFO] [WINRAW]: Mouse #0 \\?\Root#RDP_MOU#0000#{378de44c-56ef-11d1-bc8c-00a0c91
405dd}.
[INFO] [WINRAW]: Mouse #1 \\?\ACPI#IBM3780#4&2b110597&0#{378de44c-56ef-11d1-bc8c
-00a0c91405dd}.
Mouse Index
to match the indexes discovered earlier.Note that my laptop registers two mice with Windows raw even though there is only a single trackpoint. However with this as a starting point you can now configure the individual player inputs even if there is a final bit of trial and error.
Wow, that looks comprehensive. I hope to get some time tonight so this is working out good.
Well not a good start im afraid. (RA 1.6.7 nightly 24/9/17) updated mame2003 core
Couldnt find a working area51 chd/zip combo so had to use area51mxr3k.
Managed to run --verbose and see my mouse#0 1 & 2 HID#VID values in the log output. (Trackpad and 2 usb BT mouse)
With the driver set to raw i get no responce from any mouse with any index combination.
When set to dinput the screen flickers on mouse click but the crosshair is very random and jumps around on click. Invisible on movement. Which is a little odd becauseat 1st run before changing anything the crosshair would follow the mouse, all be it not closely
Update i had a rouge game opt file overriding mouse to pointer. Lol
All working on my laptop.
Nice! I hope more and more people start to take advantage of this feature