I am sure that the description of how the sensor works is correct, but I can't reconcile this with the fact that there is one point near the center of the screen that will always register a hit. I used to aim for the tree branch and hit ducks every time.
I wonder if your gun's sensor was picking up a reflection in your room. Maybe there was a bright lamp in just the right spot behind you. You can even see an example of this in the gif -- look at the white spot in the top right corner of the TV.
Which a lamp reflection in the middle of the screen would be. I.e. entire screen is black, then for the white part its the real duck - and then your lamp reflection.
No, the point is the place the gun is pointed to needs to first go black, then white. If it is a static reflection of a light that area will never be filled in with black.
They do mention in the article that early versions of the game may not have had this protection, so that could be the case with OP.
LCDs do smart processing. In the past reaction time of the crystals was also kind of slow, but that isn't a factor nowadays. It's just the various filters that are applied on top of the image to make it "pop" more.
Edit: some high-hz TVs can have 2 or even 3 frames of lag, due to having frame interpolation algorithms that take a 23.97/24/25/30/etc signal and interpolate it to the native 144hz. The frame interpolation algorithm needs to know 2 or 3 frames in advance, so it buffers up those.
An LCD has to buffer the entire frame, then process it, then display it, and there's also a small delay for the crystals to transition to the new frame.
Meanwhile, a CRT shows the frame as it's still being transmitted, while the source computer is streaming each line out from the video buffer, with only a negligible delay (analog electron beams are fast!). This means a maximum of a 1/60-second delay even if the source is composing the whole frame beforehand (double buffering).
If the source is doing computation between the scan lines (very common and even necessary on old systems, like the Atari VCS) that delay can be shrunk even further.
So then how does the TV's with things like "game mode" or whatever handle this? I assume some delay is inevitable based on your explanation (and it still feels slow) but I guess it just dumps the filtering and processing to what's bare minimum required?
> "“If the NES is just looking at the state of the photodiode, can I just point my gun at a bright light and score a hit every time?” This is another good question. The NES engineers took this cheat away by first writing a black screen and looking at the state of the photodiode, ensuring this would not be allowed. If it sees anything other than the black screen, it will record the shot as a miss. It is rumored that some very early versions of the game might not have had this bug fixed, but there has been no demonstration of such a bug to date."
It's funny that they mentioned this because my first memory of the NES was when a kid in my neighborhood got one for his birthday soon after they came out in the US. This was the kid who got every cool toy and we were all a bit jealous. At his birthday party we hooked up his NES Deluxe set (the one with the console, the light gun, and the robot that you used for Gyromite) and spent the afternoon messing with it and fighting over turns.
At some point, we found that pointing the light gun at the lamp in the room really did register as an automatic "hit" every time. Maybe this was one of these early versions or maybe it was something else. I just remember distinctly seeing the "bug" because it pissed off all the other kids when birthday boy started doing it to get the high score.
Flag on HN is only if you think a submission is not appropriate. I know other sites give it more meaning but here it is more similar to downvoting a post.
We all appreciate proper orthography, but please don't flag a story for that reason. You should flag if the article itself is bad or off-topic for HN. Missing out on good content because of a typo is the wrong tradeoff. Instead, just let us know (hn@ycombinator.com is the surest way) and we'll fix it.
I spent some time thinking about this problem a while ago, and I think I have a solution that I would never actually take the time to implement. The trick would be doing it all fast enough, which is over my head.
* Intercept the video output from the NES.
* Place a camera on the end of the zapper.
* Use static images such as the trees to determine the coordinates of where the camera is currently pointing.
* Use LEDs directly in front of the zapper's sensor adjust the light to what those coordinates would be based on the intercepted output of the NES.
The comments say the author got it wrong, essentially, and that the gun looks for a 15.7khz modulation, rather than just contrast in a certain time range. The commenter says he's used the zapper in a light-harp application and knows that the sensor cares about the modulation frequency.
The linked to video (of one working on an LCD) has been hacked to work with an LCD and is not stock, per the comments on the video.
28 comments
[ 3.5 ms ] story [ 86.1 ms ] thread[0] https://en.wikipedia.org/wiki/Moorhuhn
They do mention in the article that early versions of the game may not have had this protection, so that could be the case with OP.
Edit: some high-hz TVs can have 2 or even 3 frames of lag, due to having frame interpolation algorithms that take a 23.97/24/25/30/etc signal and interpolate it to the native 144hz. The frame interpolation algorithm needs to know 2 or 3 frames in advance, so it buffers up those.
Meanwhile, a CRT shows the frame as it's still being transmitted, while the source computer is streaming each line out from the video buffer, with only a negligible delay (analog electron beams are fast!). This means a maximum of a 1/60-second delay even if the source is composing the whole frame beforehand (double buffering).
If the source is doing computation between the scan lines (very common and even necessary on old systems, like the Atari VCS) that delay can be shrunk even further.
If you don't like the postprocessing the TV does, which I often don't, "game" mode is often a good solution.
So, it's really not much of a "myth". Most light guns worked that way. The zapper is an outlier.
It's funny that they mentioned this because my first memory of the NES was when a kid in my neighborhood got one for his birthday soon after they came out in the US. This was the kid who got every cool toy and we were all a bit jealous. At his birthday party we hooked up his NES Deluxe set (the one with the console, the light gun, and the robot that you used for Gyromite) and spent the afternoon messing with it and fighting over turns.
At some point, we found that pointing the light gun at the lamp in the room really did register as an automatic "hit" every time. Maybe this was one of these early versions or maybe it was something else. I just remember distinctly seeing the "bug" because it pissed off all the other kids when birthday boy started doing it to get the high score.
* Intercept the video output from the NES.
* Place a camera on the end of the zapper.
* Use static images such as the trees to determine the coordinates of where the camera is currently pointing.
* Use LEDs directly in front of the zapper's sensor adjust the light to what those coordinates would be based on the intercepted output of the NES.
The linked to video (of one working on an LCD) has been hacked to work with an LCD and is not stock, per the comments on the video.
Interesting!