Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie
-
@dankcushions said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
it might be that the kernel in retropie/raspian doesn't support the dolphinbar yet :(
That could be the case, and seeing as how I've also tested the high-end offerings from AimTrak previously and those from ArcadeGuns last night, the issue most likely extends further to whatever this particular class of pointer device is classified as, making any kind PC light gun an impossibility.
I have three different emulation gaming rigs for when I want to play light gun games, so this isn't really a big issue for me, but I realize there are many people who would like to play these games on the Pi. If you should ever need someone to help test gun peripherals against any changes made to RetroArch or RetroPie, just give me a shout.
-
@dankcushions said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
@johne79 said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
I don't know enough about udev/RetroArch yet to weigh in on the conversation about spoofing absolute coordinates, where's a good place to start? Is the problem actually in udev itself or is it in RetroArch or is it in lr-genesis-plus-gx?
the problem is potentially fixable in either retroarch's UDEV driver, or lr-genesis-plus-gx, but the former makes it something all cores can use.
the basic flow (as i understand it is)
- linux has access to your hardware (eg, pointer device) via UDEV
- retroarch's UDEV input driver provides access to the UDEV information (eg, a UDEV pointer device)
- the core (emulator) asks retroarch for status of a generic RETRO_DEVICE_POINTER, which the UDEV input driver provides
here is where the UDEV input driver updates the RETRO_DEVICE_POINTER's state (coordinates): https://github.com/libretro/RetroArch/blob/master/input/drivers/udev_input.c#L460
it's at this point i'd have to start debugging to work out what's going on!note, you can might see some references to RETRO_DEVICE_LIGHTGUN, but as far as i can tell this is just another way of looking at the mouse: https://github.com/libretro/RetroArch/blob/master/input/drivers/udev_input.c#L420
i guess UDEV/linux doesn't see lightgun's as anything other than mice. also, i don't know of many (any?) cores that actually use RETRO_DEVICE_LIGHTGUN - they normally ask for a POINTER or maybe a MOUSE.Considering that the buttons actually do work, i.e. when playing Missile Defense 3-D pressing the left mouse button does actually make it shoot in the middle of the screen and can kill some of the projectile missiles coming at you, I think it's safe to say that at least the RETRO_DEVICE_ID_LIGHTGUN_TRIGGER aspects of RETRO_DEVICE_LIGHTGUN are working properly.
It dawned on me while looking through the code of both RetroArch that you pointed to and in the following:
https://github.com/libretro/Genesis-Plus-GX/blob/master/libretro/libretro.c#L328&L344
https://github.com/libretro/Genesis-Plus-GX/blob/master/libretro/libretro.h#L2061&L2062So the first thing that's wrong with lr-genesis-plus-gx, look on line 330 and 331 and you'll see that ekeeke is using RETRO_DEVICE_POINTER's RETRO_DEVICE_ID_POINTER_X and RETRO_DEVICE_ID_POINTER_Y directly instead of RETRO_DEVICE_LIGHTGUN's RETRO_DEVICE_ID_LIGHTGUN_X and RETRO_DEVICE_ID_LIGHTGUN_Y respectively. That needs to change, mixing and matching input paradigms like that may have been needed at one point but it needs to be updated to match what's coming downstream from RetroArch.
If ekeeke is not going to budge on strict adherence to design i.e. he wants only a RETRO_DEVICE_POINTER to be able to be used with his core, the only places it CAN change I think are in RetroArch and udev. So right now in the game if I move the mouse by a LARGE amount on the X or Y axis I'll see some movement in the upper left. That tells me that in udev_input.c on lines 424-427 that you referenced that udev->mouse_x and udev->mouse_y are bringing back values, it's giving you the delta each time, so a big large movement has a big delta and that's the only way I can see that it's actually doing its job because it's treating those relative coordinates as absolute in this case.
So... if a udev rule (I don't know if this is possible because I haven't had to write my own custom udev rules before) were to change the mouse to an absolute pointer device it would change it system-wide I guess and that would mess up anything that needs the mouse in relative coordinates.
Barring all of that craziness, the first thing that absolutely needs to change is that lr-genesis-plus-gx needs to be using the lightgun x/y instead of pointer x/y. It should be up to RetroArch to tell what is and is not a lightgun.
Let's think about this here, I could theoretically (and IDEALLY, in fact, I was literally FRUSTRATED as a new end user the other day that I couldn't make this happen, and so it's probably going to eventually frustrate other end users who actually use the system) use a d-pad controller as an absolute positioning device in the absence of a mouse or absolute positioning device. It may not be the most usable choice, but it gives way to more accessibility options for end users. It at least lets you play without needlessly spending more money on hardware.
RetroArch needs to tell the cores downstream what is and isn't a lightgun, and the cores should adhere to that, instead of trying to tell me that a lightgun MUST be an absolute positioning device. That's I think going away from the design principles behind RetroArch, I'm just guessing as a new user (I also happen to be a hobbyist intermediate level indie game programmer and beginner level hardware engineer). I should be able to tell RetroArch what constitutes the x and y axes of the lightgun, and then it feeds that to the cores, even if that x/y comes from a gamepad's d-pad.
In fact, I want to design and develop custom open hardware doing embedded development and share those designs with the community so that you can make your own devices, rather than relying on hardware manufacturers. There's a family owned Christian electronics surplus store in my local area (DFW) that I go to that has parts for cheap, STM32 NUCLEOs for around $10-20, buttons, screens, the whole nine yards, we're talking very cheap here like $0.08 resistors and the like. Also there's a local arcade here in my town that actually sells parts to arcade games but they can be pricey on some things like trackballs. There are options though beyond existing hardware manufacturers. What if I made something like an integrated arcade joystick and trackball combo that you could use in a game? I want to use that trackball part of the device as the lightgun. Maybe instead of a trackball it could be an actual touch screen. I have a few touchscreen LCDs laying around that use ILI9341 video drivers, those could theoretically be lightgun devices.
So the gameplan to summarize is...
- Fix the parts in lr-genesis-plus-gx to reference the lightgun x/y instead of pointer x/y, there's no need to continue using pointer x/y as it should come downstream from RetroArch.
- If that doesn't fix all the problems, you'll probably have to implement a fix in RetroArch in udev_input.c around lines 424-427 after that to return an added or subtracted udev->mouse_x(/mouse_y) from 0,0 initialized coordinate variables in the case of a relative device.
- That brings in another piece of complication, will udev give any meta-information about the device if it's relative or absolute, does that come in from the HID report descriptor and get transferred through udev? If not, then the user should be able to at least have a RetroArch option to specify whether the device is absolute or relative, because udev->mouse_x and udev->mouse_y are essentially dumb to what kind of device it is.
- If I want to use a d-pad as a lightgun x and y (and SOMETIMES I DO maybe for testing or for the lack of having peripherals to keep things compact), I should be able to tell RetroArch an option of WHAT to use as the lightgun x and y. Maybe that DOESN'T come from udev->mouse(x/y) but some other arbitrary axes like from a joystick with a specified lower and upper end for each coordinate axis (also movement speed/sensitivity is another factor to account).
-
Hey everyone. I'm also eagerly awaiting some sort of a solution, as I have the same problem with my Wiimote/Dolphinbar setup. On this emulator, it fires, but I can't move the cursor, and the crosshairs don't show on the screen. I know very little about tweaking codes inside emulators, so I was going to ask what I should try tweaking (like the "gun_cursor" code) because I honestly don't know where to start when tweaking code like this
I will say though that, thanks to the AdvMame update from August (I think), my Wiimote/DolphinBar combo does work with quite a few games (Lethal Enforcers, Operation Wolf, Operation Thunderbolt, to name a few), with just a simple Wiimote (and an 8-dollar plastic gun thing) and a Dolphinbar, plugged into the first USB of my Pi. The games that don't work, seem to be actual rom issues instead of gun issues.
I also wanted to add that I was kind of surprised it even half-worked on this emulator, since I was told by someone on a retro gaming FB group that none of the libretro emulators support light guns, even though I've heard that there was gun support on lr-mame2003 and lr-mame2010, although I haven't gotten anything to work on those yet. The games that do work on my setup are largely through AdvMame 1.4., but still, I really want to find a way to get this working on SMS/Genesis and even NES.
I have tried DGen and Osmose for SMS/Genesis gun roms, and those are the opposite of this emulator. I can move the cursor (it shows up as an actual mouse cursor, not a crosshairs), but I can't shoot. If anyone has any updates/fixes, I'd be eternally grateful!:)
-
@BGallagherLA said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
Hey everyone. I'm also eagerly awaiting some sort of a solution, as I have the same problem with my Wiimote/Dolphinbar setup. On this emulator, it fires, but I can't move the cursor, and the crosshairs don't show on the screen. I know very little about tweaking codes inside emulators, so I was going to ask what I should try tweaking (like the "gun_cursor" code) because I honestly don't know where to start when tweaking code like this
I will say though that, thanks to the AdvMame update from August (I think), my Wiimote/DolphinBar combo does work with quite a few games (Lethal Enforcers, Operation Wolf, Operation Thunderbolt, to name a few), with just a simple Wiimote (and an 8-dollar plastic gun thing) and a Dolphinbar, plugged into the first USB of my Pi. The games that don't work, seem to be actual rom issues instead of gun issues.
I also wanted to add that I was kind of surprised it even half-worked on this emulator, since I was told by someone on a retro gaming FB group that none of the libretro emulators support light guns, even though I've heard that there was gun support on lr-mame2003 and lr-mame2010, although I haven't gotten anything to work on those yet. The games that do work on my setup are largely through AdvMame 1.4., but still, I really want to find a way to get this working on SMS/Genesis and even NES.
I have tried DGen and Osmose for SMS/Genesis gun roms, and those are the opposite of this emulator. I can move the cursor (it shows up as an actual mouse cursor, not a crosshairs), but I can't shoot. If anyone has any updates/fixes, I'd be eternally grateful!:)
If you can actually believe this, I had a solution, and then the MicroSD card I had RetroPie and did my code updates on literally BURNED UP when I brought my Raspberry Pi 3 to a friend's house Sunday night to show off RetroPie. The card I guess shorted when I tried to put the RPI3 in a plastic case that pressed up against the MicroSD card and may have bent/shorted it, causing it to just get extremely hot and die when plugged in.
Guess I should have bought that extra Logitech f310 gamepad for the guys, God's telling me something here. :-P
It's actually an easy fix, unfortunately ekeeke the developer is of the mindset that from a design perspective only an absolute pointer touchscreen should be used, and in a perfect world where there are no driver issues with Linux recognizing touchscreen devices that's great, but in my experience that's not the case so I respectfully disagree. Theoretically even a joypad analog thumb stick could/should be used as a lightgun pointer in a pinch when other hardware options are not available IMHO.
I just changed the code in lr-genesis-plus-gx to reference RETRO_DEVICE_LIGHTGUN instead of RETRO_DEVICE_POINTER on my end, and also put in some code to check the screen position. Although I put in a constant for the screen bounds checking instead of actually looking at a variable, so it worked fine on Missile Defense 3-D, but then when I played T2: The Arcade Game on Genesis my cursor would only go over half the screen (because the Genesis runs at a larger resolution). Easy fix, but I have to rework those sections of code, maybe I'll fork their repo into my own and just share that. I put a VirtualBox VM on this MacBook so I can have a more reliable machine to do code edits from, although VirtualBox isn't giving me Hardware Acceleration over Debian for RetroPie, so... to be continued... Hopefully I'll have that back up within a few days or weeks (I'm in an aggressive job hunt right now trying to find a part time job in programming/support that won't kill me physically because of all that smoking I used to do ended me up pre-diabetic) :( ).
-
@johne79 said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
Easy fix, but I have to rework those sections of code, maybe I'll fork their repo into my own and just share that.
That is fantastic news. I look forward to hearing more on this. Good luck on your job search.
-
@johne79 said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
It's actually an easy fix, unfortunately ekeeke the developer is of the mindset that from a design perspective only an absolute pointer touchscreen should be used, and in a perfect world where there are no driver issues with Linux recognizing touchscreen devices that's great, but in my experience that's not the case so I respectfully disagree.
i'm sort of with ekeeke here. the retroarch udev driver should be able to translate from an absolute device to a relative device and vice versa, if either doesn't exist. i've done this in mame2003 for one purpose.. i would personally prefer to fix it in udev driver eventually, then it helps all cores.
that said, when i got someone to test with a wii mote and sensor bar and a debug version of mame2003, they weren't getting any updates to RETRO_DEVICE_MOUSE, _POINTER, or _LIGHTGUN. this is for some other fault of the udev driver, and in this case you will not be able to work around it without looking into the driver.
-
@johne79 said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
It's actually an easy fix, unfortunately ekeeke the developer is of the mindset that from a design perspective only an absolute pointer touchscreen should be used, and in a perfect world where there are no driver issues with Linux recognizing touchscreen devices that's great, but in my experience that's not the case so I respectfully disagree. Theoretically even a joypad analog thumb stick could/should be used as a lightgun pointer in a pinch when other hardware options are not available IMHO.I just changed the code in lr-genesis-plus-gx to reference RETRO_DEVICE_LIGHTGUN instead of RETRO_DEVICE_POINTER on my end, and also put in some code to check the screen position. Although I put in a constant for the screen bounds checking instead of actually looking at a variable, so it worked fine on Missile Defense 3-D, but then when I played T2: The Arcade Game on Genesis my cursor would only go over half the screen (because the Genesis runs at a larger resolution). Easy fix, but I have to rework those sections of code, maybe I'll fork their repo into my own and just share that.
See, that's the thing... I don't know where to change the RETRO_DEVICE_LIGHTGUN setting. I know next to nothing about tweaking code for emulators.
Plus I saw here (https://wiki.libretro.com/index.php?title=Genesis_Plus_GX) there is an option to turn the crosshairs on, but again, I don't know how to change this. If you could help me out a bit on where to change this code, and the other codes you tweaked, I'd be very grateful.
-
@dankcushions said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
that said, when i got someone to test with a wii mote and sensor bar and a debug version of mame2003, they weren't getting any updates to RETRO_DEVICE_MOUSE, _POINTER, or _LIGHTGUN. this is for some other fault of the udev driver, and in this case you will not be able to work around it without looking into the driver.
If it would be helpful for you to have a wii mote and dolphinbar to work with, I have a set I would be glad to send your way. Get in contact with me if that would be helpful.
-
@markwkidd that's very generous! thanks, but i think i could just buy my own for pretty cheap.
one question, what is the purpose of the dolphin bar? if wiimotes are bluetooth and the sensor bar is just a couple of infrared lights that doesn't commicate with the wii, is it enough to get a usb sensor bar clone, and a knock off chinese wiimote?
if the dolphinbar is way more popular then that's probably reason enough, but i don't think i've always seen it mentioned when talking about wiimotes + pi.
-
@dankcushions said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
what is the purpose of the dolphin bar?
The DolphinBar eliminates the need for any drivers. It not only contains the two necessary infrared lights, but it also pairs directly with the WiiMote's Bluetooth and translates the data into standard USB absolute mouse coordinates and USB keyboard input. It also has a mode that will translate the data to standard USB Joystick input, which is not only useful for the Wiimotes, but also any number of controller accessories that can connect to the bottom ports. For example, when they become more widely available, I plan on picking up four NES controllers for the NES classic and connecting them to the Pi in this way, allowing for what will essentially be four first party Nintendo controllers that are "wireless".
RetroPie v4.5 • RPi3 Model B • 5.1V 2.5A PSU • 16GB SanDisk microSD • 512GB External Drive
-
@dankcushions said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
@johne79 said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
It's actually an easy fix, unfortunately ekeeke the developer is of the mindset that from a design perspective only an absolute pointer touchscreen should be used, and in a perfect world where there are no driver issues with Linux recognizing touchscreen devices that's great, but in my experience that's not the case so I respectfully disagree.
i'm sort of with ekeeke here. the retroarch udev driver should be able to translate from an absolute device to a relative device and vice versa, if either doesn't exist. i've done this in mame2003 for one purpose.. i would personally prefer to fix it in udev driver eventually, then it helps all cores.
that said, when i got someone to test with a wii mote and sensor bar and a debug version of mame2003, they weren't getting any updates to RETRO_DEVICE_MOUSE, _POINTER, or _LIGHTGUN. this is for some other fault of the udev driver, and in this case you will not be able to work around it without looking into the driver.
There's one caveat to that, and that's that I've found out that a mouse can report ABS_X and ABS_Y without having INPUT_ID_TOUCHSCREEN=1. In fact, trying to set the latter via a udev rule on this particular touchscreen (AR1100 on an Adafruit 5" HDMI Backpack Touchscreen) caused it to stop working in X11, but it was reporting ABS just fine.
What I did before the crash on Sunday was modify the RetroArch code to include ABS_X/Y in the mouse input handling, and translate those coordinates to relative for use in lightgun apps. I used 0,0 as a fixed starting point, and it seems to work fine as long as you're not using both a relative and absolute device at the same time, if you do the coordinates wrestle with each other a bit until one takes over the other it looks like.
I'm coming back around to the code, I've had a monster of a week trying to do some home improvements on my home office including some furniture building, trying to drum up some business, getting a dedicated Debian box up and running, ensuring next time that I have a more stable coding environment and don't stupidly do the code manipulation on the Pi itself since they can be a bit "accident" prone (I've broken 2 RPI's already, one was due to an accidental wiring when I first started learning GPIO, the other was due to about a 3 foot accidental drop), and a host of other things.
In fact I could never get any device to properly detect as a touchscreen, that was a point of frustration for weeks, and no one anywhere could or would give me a hand on that. At the end of the day I think the user needs a better way via an option in RetroArch to specify what device(s) to use as pointers and that should all be handled upstream in RetroArch rather than the core dictating the usage of a device, since it can break functionality unless you go and haphazardly waste money on potentially expensive hardware like ~$100 on AimTrak guns for one or two cores. So you say use RETRO_DEVICE_LIGHTGUN in the core code, but RetroArch lets you pick whether to use an absolute or relative positioning device, and handles all the coordinate translation, and you get a "best of both worlds" situation creating a win both for RetroArch and the core developers.
-
@dankcushions said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
@johne79 said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
It's actually an easy fix, unfortunately ekeeke the developer is of the mindset that from a design perspective only an absolute pointer touchscreen should be used, and in a perfect world where there are no driver issues with Linux recognizing touchscreen devices that's great, but in my experience that's not the case so I respectfully disagree.
i'm sort of with ekeeke here. the retroarch udev driver should be able to translate from an absolute device to a relative device and vice versa, if either doesn't exist. i've done this in mame2003 for one purpose.. i would personally prefer to fix it in udev driver eventually, then it helps all cores.
that said, when i got someone to test with a wii mote and sensor bar and a debug version of mame2003, they weren't getting any updates to RETRO_DEVICE_MOUSE, _POINTER, or _LIGHTGUN. this is for some other fault of the udev driver, and in this case you will not be able to work around it without looking into the driver.
Also a small note, that Dolphinbar probably failed to detect anything for the same reason my touchscreen was failing, because it's giving absolute positioning and it's detected as a mouse not as a touchscreen, which currently in RetroArch will just skip through the switch/case statement (and I fixed that until my MicroSD's unfortunate demise on Sunday).
I don't know what the actual criteria is for udev to properly detect hardware as a touchscreen at the hardware level, surely I'm hoping it's not specific vendors/product IDs in the HID.
-
@BGallagherLA said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
@johne79 said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
It's actually an easy fix, unfortunately ekeeke the developer is of the mindset that from a design perspective only an absolute pointer touchscreen should be used, and in a perfect world where there are no driver issues with Linux recognizing touchscreen devices that's great, but in my experience that's not the case so I respectfully disagree. Theoretically even a joypad analog thumb stick could/should be used as a lightgun pointer in a pinch when other hardware options are not available IMHO.I just changed the code in lr-genesis-plus-gx to reference RETRO_DEVICE_LIGHTGUN instead of RETRO_DEVICE_POINTER on my end, and also put in some code to check the screen position. Although I put in a constant for the screen bounds checking instead of actually looking at a variable, so it worked fine on Missile Defense 3-D, but then when I played T2: The Arcade Game on Genesis my cursor would only go over half the screen (because the Genesis runs at a larger resolution). Easy fix, but I have to rework those sections of code, maybe I'll fork their repo into my own and just share that.
See, that's the thing... I don't know where to change the RETRO_DEVICE_LIGHTGUN setting. I know next to nothing about tweaking code for emulators.
Plus I saw here (https://wiki.libretro.com/index.php?title=Genesis_Plus_GX) there is an option to turn the crosshairs on, but again, I don't know how to change this. If you could help me out a bit on where to change this code, and the other codes you tweaked, I'd be very grateful.
There's a core option in lr-genesis-plus-gx for gun_cursor and you just turn it on. You can either do the RGUI menu in-game (SELECT+X for me), and set it to an override then save your config (you may need to reboot the game), or launch the text-based menus before the game by pressing keys before the game launches then set gun_cursor=yes (or maybe it's true I can't remember) to a ROM option.
-
@mediamogul said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
@dankcushions said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
what is the purpose of the dolphin bar?
The DolphinBar eliminates the need for any drivers. It not only contains the two necessary infrared lights, but it also pairs directly with the WiiMote's Bluetooth and translates the data into standard USB absolute mouse coordinates and USB keyboard input. It also has a mode that will translate the data to standard USB Joystick input, which is not only useful for the Wiimotes, but also any number of controller accessories that can connect to the bottom ports. For example, when they become more widely available, I plan on picking up four NES controllers for the NES classic and connecting them to the Pi in this way, allowing for what will essentially be four first party Nintendo controllers that are "wireless".
I wonder how that works on a dual monitor setup as a mouse? I have 3 monitors in my bedroom (two running from a PC which I may add Linux to that mix, and one close to the ceiling that runs Chromecast/Apple TV), I want to be able to control the dual monitors from WiiMote. All the Windows 10 drivers for my WiiMote didn't seem to work right, at best they would only detect the buttons and not the IR Camera in FreePIE (which is the MOST important feature to me, also I can't find GlovePIE since they stopped development), if they would detect at all (I think I only got FreePIE working, all others failed to connect). I haven't tried a Linux setup yet on those because reading through docs and forum posts it looks like there's only button support in the drivers? I don't know, hopefully they have that working. I want to be able to use the IR Camera on a WiiMote as a RETRO_DEVICE_LIGHTGUN, I've even got a Cabela's Rifle enclosure for the WiiMote.
-
@johne79 said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
@dankcushions said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
@johne79 said in Light Gun (Sega Master System) on lr-genesis-plus-gx for RetroPie:
It's actually an easy fix, unfortunately ekeeke the developer is of the mindset that from a design perspective only an absolute pointer touchscreen should be used, and in a perfect world where there are no driver issues with Linux recognizing touchscreen devices that's great, but in my experience that's not the case so I respectfully disagree.
i'm sort of with ekeeke here. the retroarch udev driver should be able to translate from an absolute device to a relative device and vice versa, if either doesn't exist. i've done this in mame2003 for one purpose.. i would personally prefer to fix it in udev driver eventually, then it helps all cores.
that said, when i got someone to test with a wii mote and sensor bar and a debug version of mame2003, they weren't getting any updates to RETRO_DEVICE_MOUSE, _POINTER, or _LIGHTGUN. this is for some other fault of the udev driver, and in this case you will not be able to work around it without looking into the driver.
There's one caveat to that, and that's that I've found out that a mouse can report ABS_X and ABS_Y without having INPUT_ID_TOUCHSCREEN=1. In fact, trying to set the latter via a udev rule on this particular touchscreen (AR1100 on an Adafruit 5" HDMI Backpack Touchscreen) caused it to stop working in X11, but it was reporting ABS just fine.
What I did before the crash on Sunday was modify the RetroArch code to include ABS_X/Y in the mouse input handling, and translate those coordinates to relative for use in lightgun apps. I used 0,0 as a fixed starting point, and it seems to work fine as long as you're not using both a relative and absolute device at the same time, if you do the coordinates wrestle with each other a bit until one takes over the other it looks like.
I'm coming back around to the code, I've had a monster of a week trying to do some home improvements on my home office including some furniture building, trying to drum up some business, getting a dedicated Debian box up and running, ensuring next time that I have a more stable coding environment and don't stupidly do the code manipulation on the Pi itself since they can be a bit "accident" prone (I've broken 2 RPI's already, one was due to an accidental wiring when I first started learning GPIO, the other was due to about a 3 foot accidental drop), and a host of other things.
In fact I could never get any device to properly detect as a touchscreen, that was a point of frustration for weeks, and no one anywhere could or would give me a hand on that. At the end of the day I think the user needs a better way via an option in RetroArch to specify what device(s) to use as pointers and that should all be handled upstream in RetroArch rather than the core dictating the usage of a device, since it can break functionality unless you go and haphazardly waste money on potentially expensive hardware like ~$100 on AimTrak guns for one or two cores. So you say use RETRO_DEVICE_LIGHTGUN in the core code, but RetroArch lets you pick whether to use an absolute or relative positioning device, and handles all the coordinate translation, and you get a "best of both worlds" situation creating a win both for RetroArch and the core developers.
interesting! i think we're on similar pages.
there's one issue that RETRO_DEVICE_MOUSE/POINTER/LIGHTGUN only handles one device of the same type each (i think if you have multiple mouse/etc devices then they fight, as you say). they should be able to handle N devices, like RETRO_DEVICE_JOYPAD or whatever. issue logged for this: https://github.com/libretro/RetroArch/issues/3443
Also a small note, that Dolphinbar probably failed to detect anything for the same reason my touchscreen was failing, because it's giving absolute positioning and it's detected as a mouse not as a touchscreen, which currently in RetroArch will just skip through the switch/case statement (and I fixed that until my MicroSD's unfortunate demise on Sunday).
I don't know what the actual criteria is for udev to properly detect hardware as a touchscreen at the hardware level, surely I'm hoping it's not specific vendors/product IDs in the HID.
yeah i think fully understanding this part is crucial. if it's a udev problem, then the problem should be reported to udev upstream. if its a udev driver problem, then it's fixable in libretro. i suspect the case statement is faulty, but i don't fully understand the info that udev provides about a device to fix it. there must be SOME sort of reliable information about whether a device is abs or not... you'd hope.
i don't think it should be up to the user to specify whether something is abs or not.. ideally, anyway!
-
@johne79 Thanks John! Currently updating everything to 4.2 so I'll try tweaking with this again when that finishes.
-
@johne79 I've got a little cheap gun enclosure for my Wiimote, just a white plastic one that cost like 8 bucks on Amazon haha. Works great in AdvMame for me, and a ton cheaper than Aimtrak.
-
@johne79 I found the gun cursor setting in Retroarch GUI but it just turned the cursor on, and I still can't move it from center. Do I have to tweak more to calibrate the gun through different settings? I even turned the Player One in retroarch to "MS Light Phaser" but that didn't seem to fix anything.
-
@johne79 There is now a bounty building up for mouse enhancements to the libretro API: https://www.bountysource.com/issues/43321776-multiple-mice-support
Specifically it's about adding support for multiple mice. I remembered you getting pretty far into this analysis of what could be improved in that regard so I just wanted to point the bounty out to you. In case you might be tempted to try for it :)
-
Hi @johne79. I just wanted to mention that @casdevel from the libretro forums and github has added multi-mouse support to RetroArch's udev input driver.
If you are interested in that feature, or if you would like to see if casdevel could help address the need some cores have for absolute coordinates, here's where the discussion is happening: https://github.com/libretro/RetroArch/pull/5010
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.