How to included a touch screen in a program

[Hated Moron]

On 10/02/2023 12:50, Bart Munting wrote (cross-posted from the Discussion Group):

I have made a program in SDLIDE and put it with WASM in my website and people could play the game in their browser.

The problem came with the lack of a touch screen.

Any solutions on how to do this the good way?

I don't see the relevance of running in a browser to this question. A browser may or may not have a touchscreen: if it's running on a phone or tablet it certainly will, if it's running on a laptop it may do (such as the one I am writing this on), if it is running on a desktop PC it probably won't.

So long as you write your program so that it will run either with a touchscreen (e.g. on a mobile device) or with a keyboard and mouse (e.g. on a desktop PC) it should run OK in a browser, whether or not it has a touchscreen.

The great majority of the supplied example programs run with either a touchscreen or a keyboard and mouse. Sometimes the functionality is reduced with a touchscreen (e.g. both Rubik.bbc and pinball.bbc have additional features when there is a keyboard).

Does that help, or have I misunderstood the question?

[Hated Moron]

On 11/02/2023 07:43, Bart Munting wrote (cross-posted from the Discussion Group):

I made a game in BBCBasic for Windows(SDLIDE).

It works well on a computer and also when it is run in the browser on a computer.
I wanted it also to run on a mobile smartphone in a browser.
That failed because the program has only mouse functions.

It's standard behaviour, on all platforms, for the OS to map touchscreen gestures to mouse actions (by default). So for example if you 'tap' somewhere on the screen your program will receive the same input as if you had clicked the left mouse button. If you 'drag' your finger across the screen, your program will receive the same input as if you had held down the left mouse button and dragged the mouse pointer.

So, commonly, no modifications are needed to make a program which uses only mouse input touchscreen-compatible. The only situation when this won't happen is if your program is relying on mouse input which has no equivalent touch gesture. For example if your program uses the mouse position even when no buttons are pressed, or responds to the right or middle mouse buttons, which have no touch equivalent.

In such a case it is entirely up to you to devise some touch alternative to the mouse actions which don't have a direct touch equivalent. For example you might use a 'long press' to have the same effect as a right-click (typically to bring up a 'context menu'). Or a two-fingered 'pinch' or 'stretch' gesture to substitute for the mouse wheel (typically to control zooming).

[Hated Moron]

On 12/02/2023 07:56, Bart Munting wrote (cross-posted from the discussion group):

On my Samsung phone with chrome the keyboard does not come and so nothing happens!?

Keyboard? This is the first time you've mentioned the keyboard! You asked about how to adapt a program which uses the mouse for input so it will work on a touchscreen, and I have done my best to answer.

Indeed you said this: "[it] failed because the program has only mouse functions". Only mouse functions, implying that the keyboard isn't used at all!

I'm afraid I have no idea how to make the On Screen Keyboard appear when running as a web app in a browser. I can try asking the question at the SDL forum, but otherwise I'm as much in the dark as you.

[Hated Moron]

I'm afraid I have no idea how to make the On Screen Keyboard appear when running as a web app in a browser. I can try asking the question at the SDL forum, but otherwise I'm as much in the dark as you.

Judging by this it does not look promising. The suggestion there is to implement your own on-screen keyboard, which isn't difficult. I've made a QWERTY keyboard in BBC BASIC before (see image below, at the forum), and there's an alphabetic keyboard in hangman.bbc in the examples/games/ directory.

osk.png

[jgharston]

I'm afraid I have no idea how to make the On Screen Keyboard appear when running as a web app in a browser. I can try asking the question at the SDL forum, but otherwise I'm as much in the dark as you.

Judging by this it does not look promising

Ah, this could be the answer to another problem I've been having, both in BASIC and in JavaScript. (Or it could be me just not knowing how to control my tablet without a plug-in keyboard).

If I run my SDL BBC BASIC programs, the soft keyboard pops up. However, if the soft keyboard disappears (eg, if I go to the home screen, or I stack BBC BASIC in the background, and then restore it), I can't get the soft keyboard back! I thought I'd fixed it by doing SYS "SDL_StartTextInput" (I think, I'm typing from memory) before INPUT, GET, INKEY, but if I lose the soft keyboard in the middle of INPUT, the program can't do SDL_StartTextInput as it's in the middle of INPUT

When I get home this evening I'm toying with doing something like ON TIME SYS "SDL_StartTextInput" to see if that help, but RTR's link suggests it may be unfixable. (grumble grumble I learned to type when I was 8 and gave up finger painting grumble....)

[Hated Moron]

if I lose the soft keyboard in the middle of INPUT, the program can't do SDL_StartTextInput as it's in the middle of INPUT

That's true, but it's just one of several reasons why 'blocking' functions like INPUT and GET should generally be avoided in a GUI program, and used only in standard console-mode programs. It's why non-blocking replacement functions (FNinput and FNget) are provided in the nowait.bbc library.

When I get home this evening I'm toying with doing something like ON TIME SYS "SDL_StartTextInput" to see if that help

It won't make any difference, because it's still blocked by INPUT and GET. Use the nowait replacements and if you need to restore the on-screen keyboard use *OSK ON (I hope that will work if the keyboard has been dismissed because of putting BBC BASIC into the background, but I may not have tested that).