libretro / libretro/RetroArch

FBNeo lightgun timing

Open
#19,078 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
14.1k
Forks
2.2k
Avg merge
7h 35m
Merged PRs (30d)
51

Description

Is there an existing issue for this?
  • This is a bug in RetroArch frontend
  • I have searched the existing issues
Description

This is something I initially reported here:
https://github.com/finalburnneo/FBNeo/issues/2610

but the long and short of it is that I have spent several months figuring out all the details behind this, long after I've exhausted all the settings I can find, and the facts as I have come to see them, is that Retroarch (at least on my setup, raspberry pi) always produces a screen flash for lightguns after the gun inputs are read.

This is obviously extremely niche. Most people these days are not using a real CRT or a Guncon2, though I believe recent projects like the RGBpi2 have made it a viable cheap way to enjoy these games, and this issue will not affect guns like the sinden or 4ir, since they always know where they are. But for a Guncon2, on dark areas, it will not pick up shots on dark backgrounds, or even murky colours or reds because of the timing mismatch.

I patched FBNeo in order to:

  1. hide the trigger input
  2. flash the screen again, myself
  3. wait for a valid x/y
  4. inject the input back to the core,

It's crude, and I realised after, it doesn't preserve offscreen reloads (I was testing with point blank), but it does now work. I dropped it off to the FBNeo guys and they rightly said, it's down to the input handling of Retroarch, although to be honest, it is more prickly than that. There's probably an elegant way to do this that's not apparent to me.

Expected behavior

the frontend should read the gun position after the screen flash. but that's tricky, because it's not always apparent how many frames behind the trigger pull that is.

Steps to reproduce the bug

this is the difficult part. You'll need a guncon2, a raspberry pi/linux machine plugged into a CRT (I'm using an RGBPi2), and then just load point blank and point at a dark blue/green or black area, and observe there is no hit.

then if you use this patch, you can see the problem is "solved" (hacked)

guncon2-crt-fix.patch

Version/Commit

Version: 1.20.0 (Git b2ceb50) Feb 21 2025

Bisect Results

No response

Present in the nightly version

I don't know

Platform & operating system

aarch64

Affected Cores

FBNeo but likely others

Environment information

this is KMS/DRM, and UDEV.

I can supply an image if needed, there has been a lot of hacking to get my system up and running. But like I said, it's a niche issue. However the conclusion can also be reached to some extent by timing the frames the core produces and logging the trigger press, the co-ords, and when they're sent to burngun()

Relevant log output

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the issue on the stated Guncon2, Raspberry Pi, CRT, KMS/DRM, and UDEV setup with Point Blank, then inspect RetroArch's gun input handling and the timing around burngun(). Compare the attached guncon2-crt-fix.patch with the observed trigger, flash, coordinate, and frame timing. Done means dark-screen shots register without losing offscreen reloads.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, linux, raspberry-pi
Domain
frontend
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.