You can use lightguns on LCDs sometimes
nicole.express
nicole.express
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.
It's a pain to set up (there's linux images that have the drivers, emulators, and roms), but it supposedly works.
The price of the guns is ok, it costs about a dualsense, but the pedal is crazy expensive, and I really don't get why it costs 220 euros.
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.
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.
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.
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)
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 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.
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.)
And here we are… playing duck hunt on an LCD.
Keep on keeping on, Nicole.
http://forum.arcadecontrols.com/index.php/topic,167636.0.htm...
No shade was intended towards Nicole, she was probably a voice of reason. It’s playable enough I can enjoy it at the moment.
Glad I didn't accidentally discourage you
> 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:
> 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 wonder if we could do the same with the lightgun, have it perceive polarized light differently, and then turn up the polarized pixels properly.