Super Mario World and many other SNES (and later) games spends two frames after a controller jump input sending unchanged frames on-screen, before showing a frame where the player is jumping (tested in slow-motion camera). Emulators (and possibly FPGAs) can use run-ahead to skip past one or more of these "no change" frames, reducing input latency to match or surpass console latency (https://github.com/higan-emu/emulation-articles/tree/master/...).

Another strategy is to delay polling input computing the next frame until the end of the previous frame being drawn (RetroArch frame delay). This does not rely on the game not responding immediately to controller input, but is more prone to dropping frames if your CPU gets occupied and can't run your emulator for a few milliseconds.

It is possible to compute and display images in near-real-time over HDMI, but this technique is quite niche (https://blurbusters.com/blur-busters-lagless-raster-follower...).

Yeah, Light Gun games are always going to be an issue. Is it the latency (the white dot appearing too late, after the game code already checked), or the brightness that's the issue? I assume the former.