I'm working on a Zapper test ROM that tests the photosensor, not just the trigger as in Russian Roulette. I plan to have three "kernels", or loops that measure the timing of photosensor activation:
- yonoff: Determine on which scanline player 2's photosensor turns on and off. (This kernel is working, and I could start making single-player Zapper games right now if I wanted.)
- yon2p: Determine on which scanlines both players' photosensors turn on. (I could get this working, but only while visiting NovaYoshi because I gave him my second Zapper to play Panesian Power.)
- xyon: Determine on which scanline player 2's photosensor turns on, as well as the horizontal position of the beam to a precision of plus or minus 10 pixels or so. (I don't know if this one will ever work, but if it does, it'll allow for some heavy narrowing of targets before the hit testing phase.)
Because of the kernels' 113.667 cycle timings and the lack of a PAL NES to test with, this ROM will probably be NTSC only.
A few things I've already discovered on my Zapper + Magnavox CRT TV:
- An empty controller port and an unplugged Zapper appear as a photosensor that is constantly lit up. This is because D3 is false, just as it is when the photosensor is on. So games allowing for controller hot-swapping can reliably detect when this has occurred.
- If I aim the Zapper at a static white area, the photosensor stays on for about 26 scanlines. This is true regardless of distance from the TV, but it appears to narrow slightly if I aim at a not-entirely-white portion of the screen. The response time is slightly shorter than Nintendulator's 40 or so scanlines, but much longer than 2 on Nestopia or about 10 on FCEUX (which has a few bugs that I haven't pinned down).
More to come as I get more kernels and display test patterns working.
I'd be very interested in this as I've never been quite happy with my completely bollocky emulation of the Zapper. Having the Vaus test ROM was nice!
I tried the (x, y) code, which measures the timing of photosensor activation down to a resolution of about six cycles, on an NES. Emulators gave clean timings, but timings from my NES were very noisy, with a range of about six or seven measurement points. Really all I think I can discern is left, center, or right, definitely not enough for firing a missile at a given point on the screen, and probably not even enough to do any meaningful target rejection given that the sprite unit already limits how many targets can be on one scanline.
Vertical aiming, on the other hand, is as smooth as a Wii Remote, even with two guns at once.
I'm working on drawing some test patterns to see exactly what the Zapper will and won't recognize in order to better characterize its method of operation.
tepples wrote:
I tried the (x, y) code, which measures the timing of photosensor activation down to a resolution of about six cycles, on an NES. Emulators gave clean timings, but timings from my NES were very noisy, with a range of about six or seven measurement points.
I wonder if that follow from the resonant 16kHz demodulator on the photodiode input? Intuitively, it feels like it would produce nonlinear results on output timing...
Cool idea. You should see if you can make a calibration tool that homebrewers could include in their projects so we don't need to pull out a CRT every time we want to play a homebrew zapper game. I can see there being a lot of interest in homebrew zapper games in the future.
You'll need either a CRT SDTV or an emulator to play a Zapper game. LCDs and upscaling CRTs don't appear to have the raster scan pattern to make it work.
I've made a menu subroutine where the player can point the Zapper at an item to move a displayed cursor there and then fire to select what's under the cursor. (The Control Pad and A Button also work.) FCEUX and Nestopia are very glitchy with this menu, but it runs fine on an NES+CRT.
The time the photosensor stays on appears to depend on the average brightness within the circular "window" around the photosensor's lens. One of my line pattern tests suggests that there might not even be a 15.7 kHz resonator on the photosensor.
tepples wrote:
One of my line pattern tests suggests that there might not even be a 15.7 kHz resonator on the photosensor.
Really?? The zapper includes a sharp IR3T07, which while I can find no direct information about it, it is implied that it like the Sony CX20106A or LG GL3274 is a standard infrared demodulator IC, where the passives have been adjusted from the standard 37kHz IR frequencies down to SDTV's 16kHz carrier frequency instead. (also the photodiode from near-IR to visible light)
Also, without some kind of demodulator at either 16kHz or 60Hz, I can't figure out why it wouldn't work on a LCD TV. The
LIRC guys point out that IR receivers will respond to frequencies dramatically lower or higher than the demodulator's nominal frequency given a sufficiently loud (bright) input.
Hah. I've been lurking here for a while. First the old name for Concentration Room, and now Zap Ruder. You certainly have a dark sense of humour tepples.
This is actually a very good pun.
Just as Abraham Zapruder's movie camera captured and recorded light from the crime scene, the Zapper light gun captures and measures light from the TV. You can
download the tech demo, plug in your gun, and capture light too.
I don't really understand, but It looks like we have first Zapper test program?
Will you add X axis?(I can move "Player arrows" only with Y axis.)
But this means people will learn how to use zapper and we can see more games
So, like always, great job, tepples
Denine wrote:
Will you add X axis?(I can move "Player arrows" only with Y axis.)
The third item on the menu, "X AND Y COORDS", was my attempt to add X axis. But it turns out that on NES hardware, the time of onset of the photodiode signal is too noisy to be especially useful. See "X tracking" in README.txt and "xyon" in docs/tech notes.txt. (If it's all on one line in Windows Notepad, try opening the file in your web browser, WordPad, or Notepad++.)
Ok, i see readme-it's too complicated.Basicaly, X can be done, but it's not really useful, right?
Oh, and I wish you luck with Zap-Ping;)
Today while working on the tennis game, I added support for treating the Zapper's trigger as the A button in my controller reading code. That should help simplify some game logic in games that can use either a Zapper or a standard controller.
I have 12 more steps to do before I release tennis, and when I finish one step, I split another step into two smaller steps. I'll release once I can't split any more.
The addition of the tennis game doubled the project's compressed size, but it's smooth. Wii smooth.
Download Zap Ruder 0.02
tepples wrote:
The addition of the tennis game doubled the project's compressed size, but it's smooth. Wii smooth.
Download Zap Ruder 0.02Pretty cool. Too bad I have no way of testing it with the actual hardware (no zapper, no CRT).
ZapPing can fallback to using a controller.
Hi, Just though I'd chime in here, while browsing another thread it was mentioned that there was a lack of feedback.
I have had an opportunity to test Zap Ruder on my consoles, not only with a CRT TV, but also with a pair of first-party Zappers (one grey one orange
).
It was very surprising that the Zappers are apparently capable of accurate light detection at the horizontal raster level (I actually did not know this until I threw it into Nestopia). A quick test of the paddle game, and I knew for certain that I had to try this on the real thing.
The primary detection on the X axis, even at my TVs default settings (which are very
very dark, so that the glow of the phosphors doesn't saturate the light...that bugs me) was able to accurately pin point the horizontal scanline without any issue. As you stated earlier the Y axis tends to be 'noisy' And I did note that...although my grey Zapper showed less noise when pointed at the screen. This might be a chip revision sort of thing...I'll have to crack them both open and nab the numbers when I have some time (and more importantly, room on the desk to do so
).
When I had my dev cart running, and the tests showed acceptable results, I decided to give ZapPing a go. I plugged both controllers in and tossed the grey one to a roommate that was sitting by the set at the time. The background required me to change the brighness of the set at first (probably also why nintendo decided to use a white color), but then we ended up playing that game for about an hour. The underlying concept that a device that is normally associated with pulling the trigger and hitting a flash onscreen actually being used 'alternatively' to control a paddle was definitely an interesting concept.
I do have to say, the fluidity of the 'controller' was definitely "Wii Smooth."
The only real gripes I have with the software thus far is that the test menus are particularly tricky to navigate with the Zapper; Perhaps allowing a controller to select the menu could suffice here (or possibly smaller or more seperated targets for better control). Additionally, the only other thing I noticed was that ZapPing had no real way of letting you know that you weren't targeting the set. In WarioWare Smooth Moves the microgames that required targeting using the Sensor Bar usually would have the target object flash if they could not get a stable reading (The elephant's trunk, Mario with FLUDD, etc.). Perhaps if the Zapper cannot 'read' the screen, the paddle could flash. I say this simply because you do not necessarily need to look down the sight to aim the paddle, especially in this day and age with people used to just flicking Wii Remotes around.
Thanks for the feedback.
As for the brightness: Finding what brightnesses and hues work and don't work is one of the things the "Y COORD 1 GUN" screen is for. Try changing the hue and brightness by pressing Up, Down, Left, and Right on the Control Pad of the controller in port 1.
AWal wrote:
The only real gripes I have with the software thus far is that the test menus are particularly tricky to navigate with the Zapper; Perhaps allowing a controller to select the menu could suffice here
Did you try navigating the menu with a controller in port 1? It works with my authentic NES controller, and it works with a Super NES asciiPad through a Super NES to NES adapter that another member made me.
Quote:
Perhaps if the Zapper cannot 'read' the screen, the paddle could flash.
Good suggestion. That might help my grandma, who always drifts gradually to the right and ends up pointing offscreen (POINT PODGE) when she plays.
tepples wrote:
As for the brightness: Finding what brightnesses and hues work and don't work is one of the things the "Y COORD 1 GUN" screen is for. Try changing the hue and brightness by pressing Up, Down, Left, and Right on the Control Pad of the controller in port 1.
Did you try navigating the menu with a controller in port 1? It works with my authentic NES controller, and it works with a Super NES asciiPad through a Super NES to NES adapter that another member made me.
Didn't think to plug an actual controller in...Much easier to work the menus with that.
Wow this app is awesome! I just tried that and it felt like a freaking 8-bit wii controller! Didn't knew that the lightgun is able to scan movement like that! Nice!
(testing on original Famicom with pirate lightgun connected via ext port)
Who remembers my old
Axe music toy demo for DS homebrew? It's back as part of
Zap Ruder 0.03.
The big thing I'm missing at the moment is how to make the CPU opponent play fair. Right now it plays nearly perfectly despite using a controller.
Cool stuff!
I like the music demo, seems easy to make a catchy tune.
Yeah podge is a beast with the paddle... I couldn't get one score on him. How are you trying to keep him from perfect? Seems like once the ball is hit back and forth so many times or the ball is faster he should be more prone to failure. Or maybe even more prone to fail if his score is higher than yours.
Oh crap, this test ROM will make it all too easy for people to find the easter egg in
Years Behind using emulators
Bananmos wrote:
Oh crap, this test ROM will make it all too easy for people to find the easter egg in
Years Behind using emulators
Konami code?
Didn't notice it until Code-Data logging the rest of the game, then noticing the Data count go up when typing those keystrokes.
edit: I'll assume the real secret is something else, the stripped ROM is still missing a lot of data
Quote:
I tried the (x, y) code, which measures the timing of photosensor activation down to a resolution of about six cycles, on an NES. Emulators gave clean timings, but timings from my NES were very noisy, with a range of about six or seven measurement points. Really all I think I can discern is left, center, or right, definitely not enough for firing a missile at a given point on the screen, and probably not even enough to do any meaningful target rejection given that the sprite unit already limits how many targets can be on one scanline.
How about compensating noise by using some sort of oversampling? If you settle on a maximum number of frames of delay that are acceptable, then in frame N you could compare the noisy X coordinate with the noisy ones from frame N-1, N-2 etc. I'd say up to 5 frames of history (for a minimum update rate of 10Hz assuming PAL systems) would be decent enough to be playable if the goal is to enable determining the position of the target on a bright grid without having to blank the screen.
If you believe you can reliably determine if it is left, center or right as your post suggested, then that's a good start. From there you could convert the x positions to 3 bits for 8 candidate positions (0-7, 4-11 and 8-15).
You could then use three different tables for these three base positions. Each table would store a "most likely real X coordinate" for the history of noisy X coordiantes given by this index. With say four frames of history, you'd then need to index a 3+3+3+3 = 12bit table, meaning three of those tables would take 12kB. If that would give reliable results enough to indicate that this idea works, you could probably start optimizing by decreasing the size of your history. (and thereby the table sizes)
Yeah, I could take the median of the past five measurements. I'll consider it for 0.04. I'll also have to play with letting the player win a few points once the ball reaches certain speeds.
If you ever need anyone to test PAL versions for you, I could be your guy. Y coords work great on my powerpak, X do not. The behavior appears to be very similar in FCEUX when running in PAL mode.
Right now, the best practice if PAL NES is
detected is to multiply returned Y coordinates by 15/16 (a shift and a subtract). But should I need to make PAL NES zapkernels, I'll keep this offer in mind.
... what about X coordinates, then?
I have found X coordinates too noisy on my NTSC NES to be of any real use.
General advice: remove 7 cycles from each loop and reduce the subpixel addition to $90 instead of $AA.
tepples wrote:
The big thing I'm missing at the moment is how to make the CPU opponent play fair. Right now it plays nearly perfectly despite using a controller.
I would like to have the option to allow it to stay as it is if wanted (possibly push SELECT before the game starts, when it is asking players?), as well as a display of the total number of times the ball bounce, just in case you want to play both sides by yourself (I sometimes do this, with this game) or to have a meaningful score against the perfect opponent.
finally sat down with this to check it out last night after not having any zappers or crt's at the same time forever. really neat stuff to play around with. it's pretty impressive how accurately the gun can track on the Y axis.
I have a standard zapper and a camerica video blaster to play with. they both perform similarly on the tests. on the Y axis test, the video blaster actually has a much smaller "height" value - the indicators are overlapped. thought that was cool
one issue I have identified is the handling of "firing". playing standard duck hunt, pulling the trigger past the first click "loads" the shot, and releasing the trigger (either by letting the trigger return, or pulling it past the second click) actually fires the shot. this is analogous to the counter starting and stopping on the trigger game.
the video blaster actually has to be cocked before the trigger can be pulled.
wherever firing is used for some action on the test cart, it seems to be registering immediately rather than upon release. not so much an issue here, but I was trying out a vs. duck hunt on-a-cart hack and it's using the same behavior. again this is fine with the zapper since pulling the trigger usually means you want to shoot something.
the video blaster is different - it has a working hammer that has to be cocked before the trigger can be pulled. on this gun, setting the hammer "loads" the shot, like pulling the zapper trigger halfway. pulling the trigger releases the hammer, and with regular duck hunt, this is when the gun fires. however on the test cart and the vs duck hunt hack, the gun fires when cocking the hammer (very early, whenever it gets far enough to register). not much of an issue on the test cart, but on vs duck hunt, or if someone were to create a new zapper game like this, the game is unplayable with the video blaster. which is unfortunate because it's awesome.
To make sure I'm understanding you correctly:
* Zapper behavior: trigger reads true after partial press until 5 frames after release or full pull
* Video blaster behavior: trigger reads as true when cocked, false after fired
?
lidnariq wrote:
To make sure I'm understanding you correctly:
* Zapper behavior: trigger reads true after partial press until 5 frames after release or full pull
* Video blaster behavior: trigger reads as true when cocked, false after fired
?
right. I don't know about the exact timing of when the system is notified, but that's the general logic of it. the hammer on the video blaster is the actual trigger, and the "trigger" is just a manual release lever. I can take a crappy phone video if you want to see the test cart responding to both guns.
Nah, no need. Your confirmation of my restatement is good enough.
Now the problem becomes how to detect X the
right way, treating the screen as a 4-bit
Gray coded position encoder with one bit per frame. Is this too much of a seizure trigger?
I briefly tried a version of that test with using binary instead of grey code.
The problem I had was that the gun would move enough from vblank to vblank such that there was noticeable error in the (successive approximation ADC) that was this technique.
When I kept my hand fairly still it worked.
Just in case anyone else is looking for the Zap Ruder ROMs (cause the links in this thread are dead), the 0.03 version is available on tepples' site here:
https://pineight.com/nes/
Is Podge
punching your ass at ZapPing no matter how you shake the Zapper?
Git gud or Git out.
pinobatch/zap-ruder
This is a repack of v0.03 with no substantive code changes.
- Rebuild with Python 3 and recent ca65
- Move audio subroutine names into Pently namespace
- Move binaries from repository to release