Paddle filtering. Hysteresis, limiting changes or smoothing?

[+karri]

I am trying to add paddle support to cc65. Paddles resistance may suddenly jump due to bending of the shaft or dirt. So my feeling is that smoothing may be the wrong algorithm as it won't filter out large changes and it also dampens small movements.

 

Perhaps there could be a maximum speed of the paddle that I set depending on the game. So if there is a big jump I limit the movement of the paddle towards the desired position. This would leave the padle responsive to small movements while limiting big jumps.

 

So many algorithms. What would work best?

 

Comments?

[CPUWIZ]

1 minute ago, karri said:

I am trying to add paddle support to cc65. Paddles resistance may suddenly jump due to bending of the shaft or dirt. So my feeling is that smoothing may be the wrong algorithm as it won't filter out large changes and it also dampens small movements.

 

Perhaps there could be a maximum speed of the paddle that I set depending on the game. So if there is a big jump I limit the movement of the paddle towards the desired position. This would leave the padle responsive to small movements while limiting big jumps.

 

So many algorithms. What would work best?

 

Comments?

 

You could detect a large jump and use a slightly increased previous value instead.

[CPUWIZ]

There are obviously a few catch cases, for instance, if you move right and all of a sudden receive a huge negative delta, you'll have to detect that and apply the previous positive value as negative and slightly decreased (braking).

 

Also, I would suggest using fixed point values, easiest is obviously 8:8 and it will make it more tweakable and smoother.

[+karri]

Usually I just use hysteresis. I require several values before accepting a change. If the original value happens during the time window I just ignore the changes. This works well on a ship where waves would otherwise trigger alarms on and off all the times.

 

So I have a gut feeling to do the same for the paddle. But it feels wrong to delay the data from the paddle.

 

Another model is to think of the paddle position as a magnet that pulls the paddle towards the desired positiion. The magnet can jump back and forth but the paddle just tugs along with a certain maximum speed.

 

The actual measuring of the paddle position would be at the BLANK period. It is probably like:

 

*VBLANK = 0 // Start charging capacitor

count = 0

loop

  WSYNC

  increment count

until (INPUT & 0x80) or (count > 200)

....

*VBLANK = 0x80 // Ground capacitor to discharge it

 

I assume that I could read all 4 paddles at every frame.

 

The other thing is that for games like Klondike (Easter) I don't want absolute positions of paddles. Instead I want to register just relative movements to left/right for scrolling through lists of cards.

 

 

[+karri]

Looking at the schematics the capacitor is 0.068 (68nF perhaps). And the series resistor is 1.8k. So the RC would be between 0.12ms and 0.8ms.

 

As the 60Hz frame takes 16.6ms I wonder if sending WSYNCs for 0.8ms during the blank period affects the screen.

[RevEng]

One ground rule that I use... If the jitter duration is longer than a single frame, then you don't have much hope of removing the jitter without crushing the paddle response time. Even with your simple menu application, adding more than a frame of visual lag between moving the paddle and updating the object on screen to that position will make the control feel "floaty" to the player. IMO If the jitter is longer than a frame, then it's the responsibility for the player to clean or replace paddles.

 

A median filter of size 3 on the rolling paddle data can remove single frame jitter (which is analogous to salt and pepper noise that median filters are used on all the time) with only one frame of lag if the removed "jitter" was actually a rapid move. You need 3 bytes of storage, and the compute is relatively cheap.

 

I have more thoughts on paddle filters and the 7800, but they don't fit your application, so I'll leave the filter talk there.

 

In your application, you only need three events required to measure "left, dead, right" zones. (1) resetting the paddle cap, (2) checking if the cap is charged yet at the lef+dead boundary, (and if not) (3) checking if the cap is charged yet at the dead+right boundary. Bear in mind that the time between the three events is proportional to how much the user will have to twist the paddle to move between the zones.

 

Lastly, hitting WSYNC doesn't disturb the 7800's display, generally speaking - it's just stopping the 6502 until the end of the scanline. But you do need to be careful not to hit WSYNC near any NMI, or the NMI will be skipped, which definitely could cause issues if your game uses the NMI for display.