The light gun doesn’t need a CRT per-se, but rather the lack of input latency. Games usually flash the targets one per frame, and then it knows based on light level if you were pointing at the target and which one. If it sees light on the third frame then the target must be the third one it flashed. That requires the console to be able to read the light level basically immediately after the console’s done scanning out the image but before the phorphor fades out, so the timing is very tight.
If we made OLEDs with direct scanout/zero latency, the guns would work just fine. But because of scalers and filters there’s usually at least one frame of latency which means at best you’re one target off, or it thinks you’re cheating and registers a miss (games usually do a full frame of black first to see if the gun’s pointed at a light source, which if you have a frame of latency on the screen it’ll register the last frame which will be bright and thus register a cheat/miss).
Add just a frame of latency to a CRT and it’ll stop working there too. Later progressive scan CRTs that buffer two frames to deinterlace the signal also don’t work with the light guns.
This is correct. It has nothing to do with the underlying screen tech (it does NOT require an electron gun), but on the refresh timing.
If your emulator can tune the gun read to the screen lag, you theoretically could interrupt emulation during the blackout frames to give the gunna chance to see them, although this would almost certainly reveal the effect to the player.
If going the emulation route and willing to use a different kind of gun, you just need to feed the XY coordinates to the emulator. Duck Hunt with a Wiimote is pretty trivial to implement. Once the emulator knows the XY coordinates it can just feed the correct inputs to the game no matter the latency of the gun: if the emulated screen is a white pixel at that coordinate, then the controller port gets a one, and circumvents the entire problem. It can probably be done on original hardware too with an RP2040 to intercept the video signal and inject the correct input, as long as it knows the coordinates before sending the fire input to the console.
To make work on the original gun, the emulator could rewind and replay with the correct inputs fast enough to be completely invisible to the user, we already do that for netplay over the Internet. Play once, process the gun input, rewind and replay with the correct inputs (in the background) and then continue at the exact frame we rewound and it’s completely invisible except a tiny bit of rubberbanding.
Original console and original gun though, it’s tricky but if we could frame quadruple the thing to 240Hz and use an OLED with zero input lag, we could theorethically have it displayed in time for the console to be able to read it with the light gun by vblank. The tolerances of that would be insane.
The light gun doesn’t need a CRT per-se, but rather the lack of input latency. Games usually flash the targets one per frame, and then it knows based on light level if you were pointing at the target and which one. If it sees light on the third frame then the target must be the third one it flashed. That requires the console to be able to read the light level basically immediately after the console’s done scanning out the image but before the phorphor fades out, so the timing is very tight.
If we made OLEDs with direct scanout/zero latency, the guns would work just fine. But because of scalers and filters there’s usually at least one frame of latency which means at best you’re one target off, or it thinks you’re cheating and registers a miss (games usually do a full frame of black first to see if the gun’s pointed at a light source, which if you have a frame of latency on the screen it’ll register the last frame which will be bright and thus register a cheat/miss).
Add just a frame of latency to a CRT and it’ll stop working there too. Later progressive scan CRTs that buffer two frames to deinterlace the signal also don’t work with the light guns.
Here it is in action: https://youtu.be/V6XnSvB34y8
This is correct. It has nothing to do with the underlying screen tech (it does NOT require an electron gun), but on the refresh timing.
If your emulator can tune the gun read to the screen lag, you theoretically could interrupt emulation during the blackout frames to give the gunna chance to see them, although this would almost certainly reveal the effect to the player.
If going the emulation route and willing to use a different kind of gun, you just need to feed the XY coordinates to the emulator. Duck Hunt with a Wiimote is pretty trivial to implement. Once the emulator knows the XY coordinates it can just feed the correct inputs to the game no matter the latency of the gun: if the emulated screen is a white pixel at that coordinate, then the controller port gets a one, and circumvents the entire problem. It can probably be done on original hardware too with an RP2040 to intercept the video signal and inject the correct input, as long as it knows the coordinates before sending the fire input to the console.
To make work on the original gun, the emulator could rewind and replay with the correct inputs fast enough to be completely invisible to the user, we already do that for netplay over the Internet. Play once, process the gun input, rewind and replay with the correct inputs (in the background) and then continue at the exact frame we rewound and it’s completely invisible except a tiny bit of rubberbanding.
Original console and original gun though, it’s tricky but if we could frame quadruple the thing to 240Hz and use an OLED with zero input lag, we could theorethically have it displayed in time for the console to be able to read it with the light gun by vblank. The tolerances of that would be insane.
You can actually do it in hardware. There’s ROM hacks for the NES that let you use the light gun on LCD monitors.