1-9 pause code

[artrag]

4 minutes ago, mr_me said:

You should test for pause first, and if it's met skip the buttons test.

Or test for pause after the button test and do not shoot if the condition is met

Edited May 27, 2022 by artrag

[+DZ-Jay]

11 minutes ago, artrag said:

Or test for pause after the button test and do not shoot if the condition is met

Usually testing for pause is done first, not only because it’s an easy test, but also because the key combinations are such that they are extremely unlikely to occur accidentally either by the user or by signal noise.

 

You can do it first and get it out of the way.  Afterwards, any signal that does not look exactly like one you expect, is obviously a glitch.

 

    dZ

Edited May 27, 2022 by DZ-Jay

[+DZ-Jay]

20 hours ago, artrag said:

My game is using only left,right (i.e. D13 and D5)  and buttons (S1,S2,S3) for shooting

I've added a pause with K1+K9 but pressing K1 or K9 triggers a shoot due to the fact that lines 6 and 8 are also shared by S1

 

Here's my general recommendation for this sort of input scheme:

• First, check if the input has changed:
  • if (old_in == new_in) then skip all
• If input changed, check for K1+K9 combo:
  • if (new_in == (K1 XOR K9)) then goto pause
    • Note that (K1 ^ K9) is the same as (K3 ^ K7), so the extra combo comes for free.  Same for | instead of ^.
• If no match, then check for action button.  Since all buttons do the same thing, we only want to check if any has been pressed, but we do not care which:
  • if ((new_in & $E0) == $E0) then skip to disc detection
    • All three upper bits is either more than one button pressed simultaneously, or some stray signal.  Either way, it is not expected, so we ignore it.
  • elseif ((new_in & $E0) == 0) then skip to disc detection
    • At least two upper bits need to be set, so it cannot possibly be an action button.
  • elseif ((new_in & $E0) < 3) then skip to disc detection
    • Only one upper bit is set, so it cannot possibly be an action button.
  • else goto shoot
  • goto/fall-through to disc detection
• Check for disc using a look-up table, ignore if no match
  • Note that disc detection should cover more than just East and West -- it should include the adjacent semi-diagonals.  This expands the detection zone rather than force the player to hit precisely at the specific narrow area of each individual pressure point.

Here's an illustration of what I mean by expanding the disc detection area:

;;              F   0   1
;;         E     N  N  N     2
;;           x  '       '  x         Legend:
;;      D        ',   ,'        3    -------------
;;         W:,     ' '     ,:E       N: North    ^
;;         ::::-_   v   _:::::       E: East     >
;;     C  W::::::"> + <"::::::E  4   S: South    v
;;         :::::-'  ^  '-:::::       W: West     <
;;         W:-"    , ,    "-:E       x: Invalid
;;      B        .     .        5
;;           x  ,       ,  x
;;         A     S  S  S     6
;;              9   8   7

 

Covering the shaded areas above (East = [3, 4, 5]; West = [B, C, D]), can improve the user experience.  Another thing I recommend is to ignore any invalid or unexpected input rather than interpreting in any way.  In other words, avoid enforcing "dead-zones" on the disc.  This can also improve the user experience.

 

For example, consider the player who, in the heat of battle, presses his thumb against the disc to move to one side.  Then, while pressing under stress, slightly leans his thumb in a way that hits a perfect-diagonal.  It would frustrate the player if his ship stops moving abruptly, increasing his risk of dying or missing a shot.  These sort of things are typically registered as "glitches" by players since the behaviour was not expected.  (Remember, the disc has no notches, ridges, or marks, and the player is probably not really staring at it while pressing it.)

 

Above all, we are making the assumption that the player is using the hand-controller in good faith.  We are assuming he is playing for fun, not to "break the game," and so we oblige him with some effort to improve his experience.

 

The heuristics mentioned above are intended specifically and exclusively to avoid user errors or hardware glitches -- not to attempt to detect any misbehaviour from the player.  (My philosophy is, if the player wants to "break" my control scheme or find ways in which to subvert it, then I say, good for you, snowflake!  Have fun with your little power-trip while the rest of us enjoy playing the game for fun.)

 

    -dZ.

[+DZ-Jay]

@artrag,

 

I have some optimized assembly code for some project I was helping on, that I can share with you, in case you are interested.  The code is not exactly what you need, but I'm sure we can adjust it accordingly.  Currently it detects the following:

• Conditions and debounces the signal.
• Only processes input when debounced signal has changed.
• Pause key combo (K1+K9 or K3+K7).
• Distinguishes Top vs. Bottom action buttons, or more than two simultaneously (assuming that both sets were pressed)
• Detects all four cardinal points on the disc, in the expanded zones mentioned above: North (F, 0, 1), South (7, 8, 9), East (3, 4, 5), and West (B, C, D).

It was intended to interface with an IntyBASIC game, but that can also be altered.

 

Let me know if you would like to take a peek at it.

 

      -dZ.

Edited May 28, 2022 by DZ-Jay