Touchscreen regions

So, I'm trying to make a touchscreen interface, right? Is there a more efficient way of determining if the player is touching a specific region on the touchscreen, say if I were to make panels or something than say:

IF X<ABITRARYX AND Y<ARBITRARYY THEN
PANEL1
ELSEIF (X>ABRITRARYX AND X<OTHERPANELX) AND (Y>ARBITRARYY AND Y<OTHERPANELY) THEN
PANEL2
ENDIF

You can write a function to make things less tedious to write:

'This function takes the XY coordinates of the top-left
'corner of the panel, and its width and height in pixels,
'and returns whether or not it's being touched currently
DEF TOUCHING(X,Y,W,H)
 VAR TX,TY,TM
 TOUCH OUT TX,TY,TM
 RETURN TM && TX>=X && TX<X+W && TY>=Y && TY<Y+H
END

'If touching a 30x30 pixel panel at coordinates (50,100)...
IF TOUCHING(50,100,30,30) THEN
 ...
ENDIF

As a side note, when combining conditions like `X>100` and `X<200`, it's better to use `&&` and `||` instead of `AND` and `OR`. This is because `AND` and `OR` are actually bitwise operators, whereas `&&` and `||` are logical operators, and there are subtle differences between them. For example, they are different when either side is a number that isn't 0 or 1.

• With the logical operators, they treat 0 as false, and any other number as true. For example, `7 && 10` is 1, because both 7 and 10 are not 0.
• With the bitwise operators, they compare each bit of the left number against each bit of the right number, and the result is all of the bit comparisons together. For example, `7 AND 10` is 2, because in binary, 7 is 0111 and 10 is 1010, and the result is 0010 or 2 because that's the only bit set in both numbers.

Furthermore, logical operators will only evaluate the right side if necessary. For instance, with `0 && FUNC()`, `FUNC()` will not be executed because the answer would be 0 no matter what. Bitwise operators always evaluate both sides. So, you can see that the bitwise operators are a lot more niche than the logical operators. Typically you'll only want to use bitwise operators with `BUTTON()`. For example, you can check if the A button is being held down like this:

IF BUTTON() AND #A THEN
 ...
ENDIF

You can write a function to make things less tedious to write:

'This function takes the XY coordinates of the top-left
'corner of the panel, and its width and height in pixels,
'and returns whether or not it's being touched currently
DEF TOUCHING(X,Y,W,H)
 VAR TX,TY,TM
 TOUCH OUT TX,TY,TM
 RETURN TM && TX>=X && TX<X+W && TY>=Y && TY<Y+H
END

'If touching a 30x30 pixel panel at coordinates (50,100)...
IF TOUCHING(50,100,30,30) THEN
 ...
ENDIF

As a side note, when combining conditions like `X>100` and `X<200`, it's better to use `&&` and `||` instead of `AND` and `OR`. This is because `AND` and `OR` are actually bitwise operators, whereas `&&` and `||` are logical operators, and there are subtle differences between them. For example, they are different when either side is a number that isn't 0 or 1.

• With the logical operators, they treat 0 as false, and any other number as true. For example, `7 && 10` is 1, because both 7 and 10 are not 0.
• With the bitwise operators, they compare each bit of the left number against each bit of the right number, and the result is all of the bit comparisons together. For example, `7 AND 10` is 2, because in binary, 7 is 0111 and 10 is 1010, and the result is 0010 or 2 because that's the only bit set in both numbers.

Furthermore, logical operators will only evaluate the right side if necessary. For instance, with `0 && FUNC()`, `FUNC()` will not be executed because the answer would be 0 no matter what. Bitwise operators always evaluate both sides. So, you can see that the bitwise operators are a lot more niche than the logical operators. Typically you'll only want to use bitwise operators with `BUTTON()`. For example, you can check if the A button is being held down like this:

IF BUTTON() AND #A THEN
 ...
ENDIF

Hooooo boy. I don't completely understand it yet, but from what I could gleam, that difference sounds pretty big in the long run. Thanks a ton!

I use sprite collision for this kind of thing. (Check out either game in the Super Bearland series if you want to see it in action.) Basically I make a tiny sprite called the Cursor. It has collision physics but it's colored to be completely clear so you never see it. If you're not touching the screen, then it's hidden and moved way offscreen (example coordinates: -200, -200). But when you do touch the screen, it moves the Cursor to the same coordinates you get from TOUCH OUT X Y. Everything that's meant to be touchable either is a sprite, or has an invisible sprite covering it. (These are also set to use the same collision mask as the Cursor does.) Use the SPHITSP function to determine what your Cursor sprite is "colliding" with. The upshot of this is that when you're still working on the program, you can make all the touchable regions/cursors visible by coloring them a visible color. But when you want to publish, you can recolor them all back to totally transparent and nobody will be the wiser.