IntyBASIC Definitive Controller/Keypad De-Bouncing?

[First Spear]

This has been touched on a few times in different threads I think.

 

I am trying to capture disc-only input from Controller #2, not confusing it with keypad input.

 

My pseudo-code is

main loop:
 if cont2.key = 12 gosub disccheck
 wait
goto loop

disccheck:
If cont2.right <> 0 and cont2.up = 0 and cont2.down <> 0 Then gosub moverightonly
etc

This successfully lets a disc-push to the right only go right, it does not accept diagonals, which is what I want. However, pressing [6] on the keypad still moves to the right, which I don't want.

 

What is the right pattern for distinguishing the input?

 

 

Thanks.

[+nanochess]

Try this:

	c = cont2.button
	IF (c = $20)+(c = $40)+(c = $80) THEN GOTO skip_disc  ' Evade keypad clicks

skip_disc:

[freewheel]

This may help, or may make things more confusing. It's the actual output returned by the controller for every input, in both decimal and binary form.

 

You can use the decimal values to check for absolute explicit presses of something. You can also use the binary values (which is what nanochess is doing above by checking if any of the 3 left-most bits are set) to either include or exclude input. I find that it really depends on exactly what you're looking for.

 

I didn't bother with all 16 directions but they're just a combination of the various directionals. In fact if you look closely you'll see that the 4 diagonals are just ORing the cardinal directions together, and setting an extra bit.

 

Also one thing to consider - if you exclude all diagonals, it can make the control very clunky on the real thing. Depends on the game of course. Personally I'd rather allow for them and make a "best guess" as to what they represent (DZ has a great technique for this). That way a player can still use the disc as designed (rolling around it) and not have to have pinpoint accuracy.

 

Hopefully this looks OK:

input	dec	bin
		
nothing	0	00000000
s	1	00000001
e	2	00000010
n	4	00000100
w	8	00001000
nw	28	00011100
ne	22	00010110
sw	25	00011001
se	19	00010011
		
button0	160	10100000
button1	96	01100000
button2	192	11000000
		
key1	129	10000001
key2	65	01000001
key3	33	00100001
		
key4	130	10000010
key5	66	01000010
key6	34	00100010
		
key7	132	10000100
key8	68	01000100
key9	36	00100100
		
key10	136	10001000
key11	72	01001000
key12	40	00101000

Edited March 14, 2015 by freeweed

[intvnut]

 

Try this:

	c = cont2.button
	IF (c = $20)+(c = $40)+(c = $80) THEN GOTO skip_disc  ' Evade keypad clicks

skip_disc:

 

 

This slick trick, if I did it right, may be quite a bit faster:

.

    c = cont2.button + $100
    IF (c AND (c-1)) = $100 THEN GOTO skip_disc   ' Avoid keypad clicks

.

This trick relies on a bit-fiddling trick I learned from K & R's C book: The expression (x AND (x - 1)) clears the rightmost set bit. So what this trick does is the following:

• Add $100 to the cont2.button value. If cont2.button has any bits set of its own, they're all below $100.
• Clear the rightmost set bit. One of three things happens:
  1. If cont2.button had exactly one set bit (ie. was $20, $40, or $80), then this will clear that bit, leaving $100 as the result.
  2. If cont2.button has no bits set, it'll clear $100 to 0.
  3. If cont2.button has multiple bits set, it'll clear the rightmost of those bits, leaving a value other than $100 as the result
• Test the result to see if it's $100. The only case that would give $100 is when cont2.button returned $20, $40 or $80

Just a quick eyeball of the generated code suggests a ~2✕ speedup, in part due the costly generation of 0 / -1 for the equals comparisons. (99 cycles vs. 180, if I counted correctly. The actual comparison math is about 3✕ as fast (40 cycles vs. 123), but the other code around it doesn't speed up.)

Edited March 15, 2015 by intvnut

[+nanochess]

 

 

This slick trick, if I did it right, may be quite a bit faster:

.

    c = cont2.button + $100
    IF (c AND (c-1)) = $100 THEN GOTO skip_disc   ' Avoid keypad clicks

.

This trick relies on a bit-fiddling trick I learned from K & R's C book: The expression (x AND (x - 1)) clears the rightmost set bit. So what this trick does is the following:

• Add $100 to the cont2.button value. If cont2.button has any bits set of its own, they're all below $100.
• Clear the rightmost set bit. One of three things happens:
  1. If cont2.button had exactly one set bit (ie. was $20, $40, or $80), then this will clear that bit, leaving $100 as the result.
  2. If cont2.button has no bits set, it'll clear $100 to 0.
  3. If cont2.button has multiple bits set, it'll clear the rightmost of those bits, leaving a value other than $100 as the resutl
• Test the result to see if it's $100. The only case that would give $100 is when cont2.button returned $20, $40 or $80

Just a quick eyeball of the generated code suggests a ~2✕ speedup, in part due the costly generation of 0 / -1 for the equals comparisons. (99 cycles vs. 180, if I counted correctly. The actual comparison math is about 3✕ as fast (40 cycles vs. 123), but the other code around it doesn't speed up.)

 

Wow! a great suggestion, I remember that trick from the IOCCC usually I don't fiddle with bits in my daily work, but for the Intellivision any cycle gained is important!

 

I would suggest only to use #c because the normal c is only 8 bits.

[intvnut]

 

Wow! a great suggestion, I remember that trick from the IOCCC usually I don't fiddle with bits in my daily work, but for the Intellivision any cycle gained is important!

 

I would suggest only to use #c because the normal c is only 8 bits.

 

Ah, yes. I forgot about that.

 

I suppose you could avoid using a variable entirely with this:

.

IF ( (cont2.button + $100) AND (cont2.button + $FF) ) = $100 THEN GOTO skip_disc

.

That one also shaves another 4 cycles, coming in at 95 if I counted correctly.