Using multitouch within games like stargate

[Hated Moron]

On 17/07/2022 10:15, terryswanb wrote (cross-posted from Discussion Group):

I have tried to include multitouch to stargate.
I am using a VDU23 command to change the window size.
If I add the VDU 26 command the screen size changes.

Presumably you are talking about a mobile platform like Android or iOS? On a desktop platform (e.g. Windows, MacOS, Linux) VDU 26 won't change the size of the window, so if you have previously set its size using VDU 23 (or MODE), VDU 26 won't do anything except set the text and graphics viewports to fill the window.

But Android and iOS don't have the concept of 'window' at all, so in that case VDU 26 can't set the text and graphics viewports to the size of the window - there isn't one! - therefore they set them to the size of the screen (or at least the part of the screen to which BBC BASIC is able to output). So on such a platform you may want to avoid using VDU 26 if you don't want that side-effect.

Instead you can, if you need to, set the text and graphics viewports explicitly using VDU 28 and VDU 24.

I can see the multiple events occurring and can get sensible Y values but the X value is strange
ranging from minus numbers and then the numbers reduce from left to right across the screen.

Presumably the supplied demo program multitouch.bbc is working for you so I would suggest looking to see what differences there are between that program and yours which could explain the effect. If you come to the conclusion that it's a bug (always possible) please report as much information as you can so it can be fixed.

What does SYS 6 do (does it stop pinch scaling the screen from working)?

The documentation of *SYS says this "By default ON SYS interrupts are not generated. *SYS 2 enables ON MOUSE interrupts from SDL_FINGERDOWN, SDL_FINGERUP and SDL_FINGERMOTION events. *SYS 4 enables ON SYS interrupts from SDL_MULTIGESTURE events".

If you have specified that multi-gesture events should be sent to your program then, yes, the default actions of such events (like pinch to zoom) are of course disabled, otherwise they could easily fight each other!

[Hated Moron]

On 17/07/2022 10:15, terryswanb wrote:

I have tried to include multitouch to stargate.

I should perhaps add that (I think) none of the existing touch-compatible games use multitouch, they all use single-touch gestures like tapping or dragging (typically using MOUSE and/or ON MOUSE statements). The advantage of that (apart from being much simpler to code) is that they can also be operated using a mouse - or other pointing device like a wheel or touchpad - which makes them easier to test and not dependent on a touchscreen.

If you have concluded that the only acceptable touch-interface to your game is multi-touch then fine, but if you haven't I would suggest considering how satisfactory single-touch (or mouse) control might be.

[Hated Moron]

On 18/07/2022 12:33, terryswanb wrote:

I found out why my program was causing problems with the mulitouch program
I had issued a HEX 64 command this had the effect of causing the X value of the
touch position to be corrupted.

The coordinates are received in the 32-bit system variable @lparam%, with the x-value in the least-significant 16 bits and the y-value in the most-significant 16 bits. The following code can be used to extract the separate x and y values irrespective of the current *HEX setting:

Code: Select all

      x% = (@lparam% <<< 48) >> 48
      y% = @lparam% >> 16

It's important to use the <<< operator (which is unaffected by the *HEX mode) rather than the << operator (which performs a 32-bit or 64-bit shift according to the mode).

[Hated Moron]

Code: Select all

      x% = (@lparam% <<< 48) >> 48
      y% = @lparam% >> 16

Lest somebody takes this code too literally, I should emphasise that you must not access @lparam% twice like this in practice (its value may have changed between the two references). Rather you should pass it as a parameter to a PROC and then reference the formal parameter when separating the x- and y-coordinates.