Zap Ruder: The Zapper test ROM project
Moderator: Moderators
Re: Zap Ruder: The Zapper test ROM project
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.
General advice: remove 7 cycles from each loop and reduce the subpixel addition to $90 instead of $AA.
Re:
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.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.
(Free Hero Mesh - FOSS puzzle game engine)
-
- Posts: 260
- Joined: Mon Jan 23, 2012 11:27 pm
Re: Zap Ruder: The Zapper test ROM project
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.
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.
Re: Zap Ruder: The Zapper test ROM project
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
?
* 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
?
-
- Posts: 260
- Joined: Mon Jan 23, 2012 11:27 pm
Re: Zap Ruder: The Zapper test ROM project
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.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
?
Re: Zap Ruder: The Zapper test ROM project
Nah, no need. Your confirmation of my restatement is good enough.
Re: Zap Ruder: The Zapper test ROM project
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?
- Attachments
-
- stuf.gif (9.05 KiB) Viewed 19046 times
Re: Zap Ruder: The Zapper test ROM project
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.
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.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Zap Ruder: The Zapper test ROM project
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/
https://pineight.com/nes/
Re: Zap Ruder: The Zapper test ROM project
Is Podge punching your ass at ZapPing no matter how you shake the Zapper?
Git gud or Git out. pinobatch/zap-ruder
Git gud or Git out. pinobatch/zap-ruder
Re: Zap Ruder: The Zapper test ROM project
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
- Attachments
-
- ruder-0.03a.zip
- (79.74 KiB) Downloaded 517 times
Re: Zap Ruder: The Zapper test ROM project
I tested this with the Hyperkin zapper and a LCD. As expected, pretty much only the "how long did you hold the trigger" test worked.
In addition to the lag, seems the expectations on what is considered light change. Y-pos detection is fairly useless anyway when your TV has a lag of 5-10 frames.
edit: And oh geez, that gif above is a massive seizure trigger. Block it out and change to a link, please.
In addition to the lag, seems the expectations on what is considered light change. Y-pos detection is fairly useless anyway when your TV has a lag of 5-10 frames.
edit: And oh geez, that gif above is a massive seizure trigger. Block it out and change to a link, please.
Re: Zap Ruder: The Zapper test ROM project
That gif displays vertical ||| bars , I am just wondering if diagonal /// bars would work better.
The idea is that the sensor can probably see something like 5-10 scanlines, let's say that the bars are repeating each 6 scanlines, then (Y mod 6) would indicate whether the sensor was triggered on the right..left end of the bar.
Of course, even if 5-10 lines are visible, the 15kHz filter might require continous light in 2-5 scanlines, so that might ahrink the visible window size (and requires bars that output light in continous lines).
Another idea, to disguise the flickering: one could do a full screen flicker for the coarse position, then flicker only the required screen area while narrowing down the exact position. That way it might even look like a wanted smoke cloud effect.
While light gun reading is technically interesting, most actual light gun games are either extremely dumb, or promoting real life gun use, or both : /
The idea is that the sensor can probably see something like 5-10 scanlines, let's say that the bars are repeating each 6 scanlines, then (Y mod 6) would indicate whether the sensor was triggered on the right..left end of the bar.
Of course, even if 5-10 lines are visible, the 15kHz filter might require continous light in 2-5 scanlines, so that might ahrink the visible window size (and requires bars that output light in continous lines).
Another idea, to disguise the flickering: one could do a full screen flicker for the coarse position, then flicker only the required screen area while narrowing down the exact position. That way it might even look like a wanted smoke cloud effect.
While light gun reading is technically interesting, most actual light gun games are either extremely dumb, or promoting real life gun use, or both : /