Cursor/Mouse Position does not align with Crosshair in Ligh Gun Games (RAW INPUT)

[JRPGod]

Most recent official release of Retroarch for Windows (64-bit) finally fixed a persisting issue with RAW INPUT DRIVERS and Sensor-Based USB Guns (Aimtraks and EMS TopGuns), allowing the guns to finally actually work in retroarch (cursor shows, and can control the menu with guns as you'd expect), however it's still busted for actual emulation. Tested with Genesis and SNES cores, tried all possible video settings (resolutions, aspect ratios, etc.) to see if it was a resolution issue - No changes.

Expected behavior

The crosshair for the lightgun in games that support it would line up with the cursor position in retroarch menu.

Actual behavior

Huge misalignment. Again, the devices work fine for controlling the cursor in the menu, start a game, even in 1920x1080 (my desktop res.) stretching to fill the window, and it's not even close.

Steps to reproduce the bug

1. Set RAW input
2. Configure your devices to appropriate mouse values in config.
3. Confirm that the cursor is working as expected for menu operations.
4. Load a light gun game
5. :(

Bisect Results

Well the latest version that got pushed a couple days ago (1.6.9) finally fixed the alignment issues in the menu. It used to be before this update you could configure the devices, and the issue with misalignment would occur in the menus as well. When I saw that this update finally fixed the guns working in the menu I was so sure the issues would be fixed in general, buuuuut....

Version/Commit

1.6.9 Official

Tested with: Win10 64-bit

EDIT: Turns out it's even worse. Despite mouse 100% being assigned the right device index as evidences by it working in the menu, player 1 is not detected at all in MD and player 2 can only shoot but not control the crosshairs at all, this is in fact even worse than the Super Scope. My guess it has something to do with translating Retroarch's raw inputs to w/e the cores are using, and effectively not actually doing it. It's closer though now I think?

[hiddenasbestos]

Since you're talking about cores that don't use the new lightgun API, I'm not sure this will help any, but I've just submitted PR #5805 which will let you test the Beetle Saturn and Beetle PlayStation cores lightguns - although support for guns on those platforms is still early days and may cloud any issues you have with the front-end.

[ghost]

@JRPGod raw input drivers (not just Windows raw) can't do what you expect. If you want to know why, let me know and I'll explain in more details.

@hiddenasbestos if you want to improve Libretro API consider removing RETRO_DEVICE_LIGHTGUN from the API.

[JRPGod]

@casdevel thanks for getting back to me, yes I would love an explanation because unless I poorly explained what I believe to be the situation/issue I have multiple other games/utilities/whathaveyou that utilise raw_input in this fashion.

[hiddenasbestos]

@casdevel I don't think removing things from API v1 is permitted. Feel free to suggest this over at https://github.com/libretro/libretro-arb for API v2

[ghost]

@JRPGod raw input drivers receive pointer coordinates that are not post-processed, while OS pointer coordinates are result of (user defined) post-processing (e.g. speed, acceleration, precision ...). After OS start, and if user didn't moved pointing device(s), raw input pointer coordinates should match OS pointer coordinates but as soon user moves the pointer this will change, and will continue to change on every movement of the pointer.

Systems with multiple mouse-like devices have additional problem which also can't be solved. All of those devices control OS pointer simultaneously, hence OS pointer coordinates are the sum off all mice coordinates (but none in particular).