(Linux) Lightguns don't work

[SeongGino]

Whereas the original DuckStation core worked with lightguns acting as mouse devices, SwanStation seems to have broken tracking functionality entirely.

Buttons respond, but the trigger just shoots offscreen in the top-left corner, making calibration and normal gameplay impossible. This is regardless of input driver, as the issue is reproducible with both x and udev drivers.

Game's controller mode is selected/overridden as "Namco Guncon".

This isn't the system or RetroArch, seeing as current FBNeo, Flycast, and other cores work with the lightgun device just fine (mainly using udev).

Observed on Arch Linux w/ RetroArch release 1.10.3, using latest SwanStation core.

[DarthMew]

Try setting "Core Provided Aspect Ratio" to auto.

[SeongGino]

I was using 4:3 by default. It seems like any of the pre-defined aspect ratios (4:3, 16:9, etc., and even Custom) is broken in that respect; but only if started in that ratio. If I toggle between another setting and then back (which ones don't matter), the gun sight does work; but this does not persist between core boots.

Trying some of the others: the "Auto" scaler as you'd suggested, seems slightly too narrow enough to cause some x-axis drifting towards the edges (which hampers aim accuracy). "PAR 1:1" is fine in this respect, and has otherwise the same look as 4:3 in the case of games that render using common progressive res's, like Point Blank. Any core provided ar's wider than 4:3 or a PAR equivalent seemingly has severe y-axis drifting - which, afaik at a RetroArch level, has been fixed with libretro/RetroArch#13258 so I'm not sure why this would be an issue in this core.

Said issues happens regardless of the RetroArch AR setting, whether Core Provided or PAR from the frontend rather than the core.

[DarthMew]

It's because of how the GunCon gets the screen coordinates it needs to position itself (which is all handled by the core).

As it turns out, it relies on the screen resizing itself to initiate the coordinates it needs to position the cursor, which means that, unless you change the core provided AR after boot, it won't be able to get any useful coordinates with any AR other than 'auto' or PAR. And even then, whenever the width and height change when using any of the ARs besides 'auto' or PAR, it won't update the coordinate scaling, meaning you'd have to change the AR again to fix the scaling.

I haven't been able to find a proper fix for this due to how the core code works, and having the core provided AR set to 'auto' as default has in the past shown to be rather taxing on lower end hardware with certain games that modify the AR to create, for example, screen shaking effects.

[rtomasa]

As the creator of RGB-Pi OS RPi Linux distribution and collaborator in the Linux GunCon2 driver, I can only say that the gun works perfectly fine with this core. The only requirements are to start RA with:

--device=1:260
input_joypad_driver = "udev"
input_player1_mouse_index = "0"

Of course, you need to use both native vertical resolutions and native refresh rates to properly work, which is probably what is failing here.

[SeongGino]

As the creator of RGB-Pi OS RPi Linux distribution and collaborator in the Linux GunCon2 driver, I can only say that the gun works perfectly fine with this core. The only requirements are to start RA with:

--device=1:260
input_joypad_driver = "udev"
input_player1_mouse_index = "0"

Of course, you need to use both native vertical resolutions and native refresh rates to properly work, which is probably what is failing here.

I had not received any notification of this issue being addressed in any recent commits, and it had been a while since I'd initially reported on this.

Unfortunately, the issue still persists: if the display ratio isn't set to Auto or Uncorrected 1:1 initially, the emulated gun doesn't track at all and won't make it past calibration.

I'm not sure what your implying at the end there? I can see the native vertical resolution thing (which I have mentioned in prior comment), but what do you mean by native refresh rate? You mean the 60hz that RetroArch vsyncs to on my traditional monitor with an NTSC game? What does that have to do with anything here? The issues I outlined in my earlier correspondence still apply to this day, just from casually re-inspecting the situation on my current RA and swanstation setup (updated as of making this comment, just to be sure).

[rtomasa]

All PSX games change several times both X and Y resolution on the fly during the gameplay, menus, CGIs, etc. If you force a fixed resolution in Y, the GCON driver information won't match with the core internal native resolution and will fail. GCON reads the light beam in each scanline and that must match with the vertical resolution of the game. Also the gun is sensible to deviations in the refresh rates meaning that erratic reads could happen when not using real refresh rates but forcing rounded 60 or 50hz instead

[SeongGino]

Only one of those really explains one of the problems outlined in the issue thus far; but still doesn't account for when the core is forced to render in a fixed 4:3 output and refuses emulated gun tracking - which was already pointed out by the maintainer here - which has yet to be addressed - which still makes the issue relevant.

I'm not seeing any source code for RGB-Pi OS or what modifications it makes to RetroArch, if any, to verify, so I can only guess that it doesn't use any aspect ratio correction - which I'd already discussed earlier that it's the only way to make tracking work on this core. Exact same host system is working just fine with any other gun-supported core using udev input and setting the correct mouse device index.

Honestly, I would rename the issue to be more descriptive (the original title is pretty vague and... um, bad), but I'm not aware of how this might affect Windows users as well.

[rtomasa]

In CRT, you should only use 1:1 to get same aspect ratio as in the Original system. My OS implements a custom RA (repo is public) that includes DynaRes for dynamic resolutions and can work in both native mode and SuperX which uses native vertical and a very specialized horizontal dynamic integer scale resolution (all using native refresh rates). The other configurations are the ones I already provided in my first comment. Do note that the core works the same as real hardware in the sense that gun must be player 1