Hardware problem, getKey glitch, or fail?

[JustCause]

Code: Select All | Copy To Clipboard

1 2	:Repeat getKey(1) and getKey(2) and getKey(3) and getKey(4) and getKey(43) :End

The loop is exited not only on (all arrows) + S, but on (all arrows) + X. And it confuses me. Am I doing something wrong? Is this a glitch? Or is my calc just broken?

[tloz128]

is this basic or axe?

[yunhua98]

I think it's supposed to be:

Code: Select All | Copy To Clipboard

1 2 3

:Repeat getKey(1) and (getKey(2) and (getKey(3) and (getKey(4) and (getKey(43) :End

although I'm not sure why.

[nemo]

it's a hardware glitch. your code is fine. there really isn't much you can do about it, and i forget how someone explained it to me, but basically keys close to each other are grouped together, and so sometimes they intercept each other accidentally. the arrow keys are mapped separately so you don't see this problem with them.

[JustCause]

I have tried that too. No luck. Also, I'm on Axe 0.4.4.

E: Ninja'd. Thx Nemo. Any idea of which keys are grouped?

[tloz128]

well you could try this

Code: Select All | Copy To Clipboard

1 2 3

:Repeat (getKey(1)) and (getKey(2)) and (getKey(3)) and (getKey(4)) and (getKey(43)) :End

EDIT: nvm Nemo's got it covered

[nemo]

justcause, no i don't know exactly which keys. generally the keys of the alpha-region (A-Z) have issues with detecting

[JustCause]

in other words, all the keys except arrows? LOL kthx

[nemo]

yeah pretty much. i mean it's a random occurence, so it's not going to happen all the time but if you're writing a text input routine and when you press a letter, a different letter shows up, you know why.

[JustCause]

Oh.

...well that makes me sad

Thanks nemo!

[thepenguin77]

Yay, I get to explain this again.

Ok, The way the keyboard works is that you have the keys lined up on a grid. The grid is not exactly apparent the way the keys are laid out, but nonetheless it is there. To see what keys are being pressed, the calculator sends a current down one of the columns, it then sees which of the rows return the voltage. This shows the calculator which keys are being pressed.

This sounds flawless, and it usually is. But what happens when you press so many buttons that you build bridges? Here is an example:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6

1  2    |  | 1--A--B-- 2--C--D--    |  |

Let's say that you press A. When the calculator sends a voltage down column 1, row returns the current and the calculator knows that A is pressed. When you press B, the voltage from column 2 gets directed to row 1.

Now press A, B, and D. The calculator sends a voltage down column 1 which gets redirect to row 1 like normal. But the voltage also flows to B then D and then to the row 2 receptor. The calculator thinks that C is being pressed too! There's the problem.

Here is the table of the calculator buttons. Use it like you would use the chart above to see where your problems will arise.

[DJ Omnimaga]

it's a hardware glitch. your code is fine. there really isn't much you can do about it, and i forget how someone explained it to me, but basically keys close to each other are grouped together, and so sometimes they intercept each other accidentally. the arrow keys are mapped separately so you don't see this problem with them.

Yeah Thepenguin77 found this a while ago (see post above me for re-explanation ). I noticed this too while working on a 4 level grayscale demo (hardcoded grayscale, before Axe added native 4 lv grayscale support). When pressing certain keys together, it wouldn't let me move left, if I remember. It can make certain games hard to design. X.x

[JustCause]

That helps a LOT. Thanks everyone!

[ztrumpet]

I made this program: http://www.omnimaga.org/index.php?topic=5055.0
This can be used to check for conflicts more visually than the table.

[DJ Omnimaga]

Yeah I just saw it, thanks a lot for this