There's also different type of lightgun, that was used in arcade shooters: it flashes whole white frame, and measures exact delay of scanning beam determining arbitrary X-Y position. This doesn't work at all on LCD, but I wonder whether it be done by drawing rainbow frame that encodes pixel position as equation of pixel color values, and using RGB sensor in the gun.
The IBM EGA had a "light pen" feature which functioned similarly (the CRTC had registers dedicated to this), but it seems to have been little-used and disappeared with the VGA.
Yes. In fact, "gun latches position counters using CRT beam timing" is the common approach. As far as I'm aware, blanking out white boxes to do a single target test per frame is something exclusive to the NES Zapper, and I'm not sure why Nintendo built things out this way.
If I were engineering a light gun from a blank slate, I would probably first try Nintendo's method and see if I could meet requirements that way. It seems less timing-dependent and faster to market. It may also reduce the differences between NTSC and PAL versions of the product.
Of course, blanking out the target for a frame makes the solution not scale well to a large number of targets. Presumably, one would perform something like a binary search (flash all targets, then flash half the targets if there was a hit somewhere, etc.) for a large number of targets.
There's a way to play lightgun games on modern TVs. It's called the Sinden, and it has a camera in the gun that looks at your TV, and figures out where you were pointing when you pulled the trigger. It draws a white border around the screen (to determined aim), and needs to roll back the emulator to register the shot.
It's a pain to set up (there's linux images that have the drivers, emulators, and roms), but it supposedly works.
In addition to this, it requires that you run their software on a pi or similar _for each gun_, which makes the gun essentially a webcam inside an arcade gun housing.
It also requires an OSSC or similar to add an ugly ass border around your game which I guess some people don't really mind, but for darker/atmospheric games it would ruin the vibe, imo.
Better alternative is gun4ir but the guy that made it started open source then closed when he realised he could make some bucks.
I've been keen to start a project for a fully open one myself but I just haven't found the time. Perhaps over Christmas.
I was looking into using this https://www.pixart.com/products-detail/45/PAJ7025R2 but pixart are unfriendly corpos and want an NDA signed before they hand over docs. I just like this part because it's a compact single module; their "proprietary" subpixel stuff isn't even that hard to do. These are the guys that make the wiimote part that is also used for the gun4ir project, it's cool tech but the NDA rubs me the wrong way - it's very uncertain if distribution of code to control their module could be considered breaking NDA...
Alternatively I was considering looking at just using a plain old arducam with an infrared pass lens and either a tang nano fpga or some microcontroller for processing (y no esp32 with bluetooth & mipi csi port waaaah).
I'm also keen to try experimenting with passive retroreflectors instead of active IR led modules as it's just incredibly annoying to attach them to your screen/power them. I've also been researching what infrared power levels are considered eye safe and so far it seems pretty difficult to get to the point where you'd damage eyes.
Gun4ir project uses the wiimote sensor. However it uses multiple ir sources than the single "sensor bar" of the wii. It's just that the company who makes the sensor, Pixart seem very unfriendly to hobbyists. Hell even buying the sensor from say https://uk.robotshop.com/products/ir-tracking-camera now links to PDFs with some "sample code" but no actual real datasheet (because of Pixart NDA). Which is funny because only a short while ago everyone was linking to a wiimote hacking wiki.
There are no officially available docs for this part - afaik the part was specifically made/manufactured for Nintendo and there does not seem to be an option to get the original datasheet even if you're willing to sign an NDA.
They do have newer sensors in the same range though, that are capable of tracking even more points.
> The problem is, a CRT TV draws frames in real time. The Nintendo knows that when it draws a frame, that frame drawing is corresponding with the moving electron beam of the television in real time. In fact, NESdev claims that the photodiodes use have their signal die in as short as 10 scanlines, so the game needs to check more frequently than the 60Hz clock that usually governs an NES game.
Hell, my solar panel (which reacts slower than a photodiode) has its response to green/blue phosphors die in 1-2 480p scanlines (which last half as long as 240p scanlines)! Though if hooked up to a high series resistance, it takes a looot longer for the charge to dissipate.
I suspect the difference in switch-off times between a Zapper and Light Phaser is related to the support circuitry (https://hackaday.io/project/9782-nes-zapper-video-synth-ther..., capacitors? transistors?!) translating the photodiode's signal to the controller pin. Series capacitors will block continuous light, and higher resistances will make a short signal last longer before dissipating.
> This would take a lot of frames to check every single letter if this worked the same way as the Zapper.
You could binary-search to find which letter was shot, though this would obviously fail if the user is moving the light gun between letters. It would probably be more reliable if the lit-up region wasn't just a small box but the entire grid cell.
> But look at what we’ve done here: the Master System is literally reading in-line with the electron beam. This means that for this to work, you really do need an electron beam that moves in sync with the VDP. An LCD just won’t give you that moving dot, no matter how much delay you add.
What's the latency of CRT composite chroma decoding? (EDIT: http://www.hawestv.com/mtv_color/delayline.htm says luma is delayed by 1.3 us to match chroma. Compare to the total scanline duration of 63.7 us, or visible duration of around 51 us.)
How many pixels does that shift the light gun? (1.3 / 51) * 256 px = around 6.5 pixels. It's possible that Master System games compensate for this delay using an empirically tuned horizontal offset.
Using today's technology, wouldn't it be possible to equip lightgun with a mini camera, process the image to determine corners of the screen it's looking at, and from that calculate its position/direction?
Kind of like how QR codes are scanned using phone camera.
If needed, one could even upload a display frame (current or near-future one) to the lightgun for use as reference.
Probably this would take some calibration, and sure the image processing would take some cpu/specialized processing hardware, but this being 2023 sounds doable, no? (if not done already)
That's pretty much what a WiiMote does, except it's not looking at corners of the screen, it's looking at infra-red lights on the "sensor bar". That's how the lightgunverter linked at the bottom of the article does it. https://www.lightgunverter.com/features.html
I dismantled one of these as a kid. Ok, technically it was my friend's Commodore 64 light pen, but it worked on the same principle.
To my surprise the only active component in it was a LM741 Opamp, and I was like: "That's what I know!". So I rebuilt one, without understanding much how it functioned. Because I didn't have much money and housings were expensive I built it into a matchbox, whose frontside fits a 9 pin D-sub connector quite nicely. The photodiode lived in a ballpoint pen and both were connected by a homemade coiled cable. It looked sweet and I must still have it somewhere.
The precision was terrible and I couldn't paint with it, but it was no worse than the original. So next time you play one of these old shooting games and you miss a lot, it's maybe not your bad aim even.
I see that I not was the only person that thought about putting a delay to make lightguns work with LCDs.
I would like to know what kind of technique uses the Amstrad's lightgun for ZX Spectrum +2+/3 (I had one as child). I had good memories of playing Operation Wolf for Spectrum using a lightgun.
My first thought upon seeing comments mention delays in LCDs was the lag compensation feature that retroarch has. (or negative input delay, whatever they call it)
It works by reading your input, rewinding some number of frames, sending that input into the game, and fast-forwarding to the frame you should be on. Probably more reliable than patching individual games. I assume it should work for most NES games, if dialled in correctly. (assuming the light meter value gets handled correctly.)
I approached Nicole recently with a mostly complete project I felt might be appropriate for her blog, and I thought she’d have the connections to get it across the finish line. And the response was a polite “why would anyone bother with this?”
I remember this email chain! I didn't realize you were asking for help, sorry about that... I don't really have any connections when it comes to controllers.
> Pretty much all analog video signals, RGB or otherwise, are imitating the raster of a television.
> That is to say, it assumes there is only a dot being drawn on screen at a time, and it provides signals that are timed as that dot moves across the screen.
I found it difficult to understand what all this meant for a long time. This is the best video I've ever found about the matter, just in case it helps others:
I built a projector with a ripped apart 15" LCD monitor and overhead projector decades ago, and we could not have been more excited to do some shooter games. We had had a PS2 and light guns all rigged up ready to go, before we noticed the fine print: does not work on projectors, does not work on LCD. And we were running via a tv-input card on a computer. It did not work for us. Delighted to see someone who made it further than we did.
> Why does it only check two? It thinks it figured out who I shot. And there’s the problem; I was pointing the gun at an LCD TV; a small widescreen monitor I keep next to my desktop alongside a CRT as a test setup.
> By the time the screen shows the white frames, the game already thinks you lost and went out to do something else.
Just so I understand correctly, did the game think the author shot the middle character? Just because it checked the middle character first and light was detected (due to the delay)?
I used to enjoy playing lightgun games with my SO on the PS2, so was devastated when new consoles seemingly no longer had light gun games. Thankfully, the oculus quest 2 has pistol whip etc. Would be interesting to see how those are processed/calculated in terms of target acquisition; do they use the little cameras in front to extrapolate positioning?
So, there used to be these 3D TVs and monitors that had pixels with different polarization on different scanlines. So with polarized glasses, it was possible to see the 3D image.
I wonder if we could do the same with the lightgun, have it perceive polarized light differently, and then turn up the polarized pixels properly.
