Detect if touch screen is present

[Jaan]

Gidday All.

Is there any way to detect if a touch screen is present?

My game can be controlled by touch, mouse and gamepad. Obviously this is not a mobile game. I would like to detect if a touch screen is present. That way I can display a custom cursor if not, and give the choice to use a cursor if there is a touch display.

Thanks all!

 

[TsukaYuriko]

I'm not aware of a way to detect this, at least not in GML.

Regardless of whether it's possible, I'd provide the user with a choice when they start the game - responding to all possible input methods - which input method(s) they'd like to use.

I'd also recommend steering away from any kind of "automatic recognition" regarding input methods, or if you do implement it, await the player's unmistakable confirmation whether the correct input method was recognized. Also, take care not to lock the player out of certain input methods. I regularly run into scenarios where games detect a controller being plugged in and will subsequently straight up refuse to accept input from anything else... and you'd better believe I'm gonna be grumpy for the rest of the day if you make me get up and walk to the back of the table to unplug my controller just so I can play a game.

 

[Jaan]

Hi.

Thanks for the quick reply. So the idea was to hide the custom cursor if using touch because it covers up parts of the menu icons and seems unpolished when using touch. But the cursor is necessary for mouse control. All input methods will be available all the time. That way I can display a mouse cursor at game start and if touch is detected the cursor can be hidden. Move the mouse or gamepad at any time and cursor displays.

In the end the game is for my 3 year old daughter so if I don't get it perfect it doesn't matter. But for the learning experience...

Is it possible to differentiate between a tap and a mouse click? I've been having trouble doing so.

My code is very simple:
For menus I've been using device_mouse_button_check_pressed() followed by a position_meeting() to detect which button instance and then run appropriate code.
For moving her little mermaid I'm using device_mouse_x() and device_mouse_y() as a target and move_towards_point() to move the player instance.

This works well. However (from my understanding of the manual) this is registered as a mouse click/location whether using touch display or mouse. So, if I could determine differentiate between touch and mouse I could display/hide cursors as appropriate.

Cheers!

 

[kburkhart84]

This works well. However (from my understanding of the manual) this is registered as a mouse click/location whether using touch display or mouse. So, if I could determine differentiate between touch and mouse I could display/hide cursors as appropriate.

In GML itself, no, there is no real way to know for sure if the input came from a touch or a mouse click. Worse, though you can say what kind of device you are on through some constants that GML provides, that still won't tell the whole story because even on mobile devices you can typically attach a mouse and keyboard.

As Tsuka said above, even if there is a way, your best bet is to simply give the user a choice. Make the custom cursor an option they can change on their own. And make the game work with or without the cursor.

 

[chamaeleon]

One could perhaps implement a small extension that checks for this. On Windows it would probably mean wrapping the function GetCursorInfo() and extract the bit information for CURSOR_SUPRESSED, perhaps. This extension function could then return true or false based on this. Hiding or displaying a cursor in GML could then be done dynamically based on this.

Paging @Samuel Venable just in case he feels like writing something.

 

[Jaan]

Thanks all for your answers.

I've decided on an unobtrusive way to give the user a choice and will run with that. I'll also look at chamaeleon's idea. Even if I decide not to implement it I'll have learnt something.

Cheers again!

 

[Pelican Police]

I'm not aware of a way to detect this, at least not in GML.

There's no device_is_touch_enabled, but there's telltale behaviour that gives it away one way or another, which could remove the need for prompting the user.

For example, if the mouse is moving while not being pressed, that's a mouse (and you can display a cursor). The only time this doesn't work is if you have a proximity stylus that moves the mouse when close to the screen. But for distinguishing between mouse and swipe, this is usually pretty reliable. And if they're using this kind of stylus, it's possible you'd want to display a cursor anyway, because then you can have a nice "on hover" animation.

The other one is having a look at device_mouse_* functions, as they take an argument called "device" which is a number from 0 through 4 (for different fingers). If the mouse x/y of a device other than 0 changes, that means they used two fingers which is not possible with a mouse.

I'd provide the user with a choice when they start the game - responding to all possible input methods - which input method(s) they'd like to use.

Or even better, accept all input methods always, and then it's one less thing for the player to think about.

games detect a controller being plugged in and will subsequently straight up refuse to accept input from anything else... and you'd better believe I'm gonna be grumpy for the rest of the day if you make me get up and walk to the back of the table to unplug my controller just so I can play a game.

But this is a really really good point, I've never considered this scenario before

 

[TsukaYuriko]

Or even better, accept all input methods always, and then it's one less thing for the player to think about.

It's actually one more thing to think about if you don't want one of those input methods to be accepted, especially when they're not recognized correctly.

I'd include the option to disable certain input methods (before the "real" game starts, or even just in a config file to really make it "one less thing for the player to think about" unless they need it) because - to draw from another scenario I've experienced myself - I've had a few cases where games incorrectly register my controller's inputs, such as registering an input as being active (generally the L and R triggers on my GCN controller) because they think it's an "axis" (positive and negative throttle around a center point) style input being pushed all the way to one side when it's really a "trigger" (positive throttle only) style input that's idle.

The most recent example that comes to mind is Disgaea 5. For one, my controller doesn't have enough inputs to cover all of the game's controls. I work around this by mapping my controller inputs to my keyboard and only mapping the most important stuff. So far, so good. However, the game permanently registers my controller's input, so even when it's being mapped to my keyboard, it still registers the default controller mapping's inputs. Pressing up therefore moves my cursor up twice in menus. Not so good.

The only way I've managed to play the game is by starting the whole controller mapping chain after I start the game, which - for the most part - bypasses controller input detection for whatever reason (presumably because the game does the whole "educated guess about how the player wants to play the game" thing... but only at the start). The one exception to this is the Innocent Farm, which for some reason still registers controller input, thinks my L trigger is permanently pressed and thus endlessly spins the camera. There's also no way to completely disable controller input detection in the game's settings.

This example is merely about a screen I don't spend a lot of time on, but if the same mishap happened with the game's actual in-game camera, that would be a massive turn-off. If I didn't like the game (or series), I wouldn't be willing to jump through these hoops to play it. Chances are most people who are reading this don't already have a million-dollar franchise running and may lose potential customers due to an oversight like this.


Game developers are spending unspeakable amounts of money into somehow optimizing the rendering of graphics so their games at least sort of run even on slightly older devices and create these massive tier lists of which specs you need to play the game on which settings... so since we're given flexible options which hardware we can play the games on and that costs millions at times, it can't be such an outlandish consideration to have a simple on/off toggle for input methods to let us also pick the input method and avoid almost comical incidents like permanently spinning cameras.

 

[Pelican Police]

I've had a few cases where games incorrectly register my controller's inputs, such as registering an input as being active (generally the L and R triggers on my GCN controller) because they think it's an "axis" (positive and negative throttle around a center point) style input being pushed all the way to one side when it's really a "trigger" (positive throttle only) style input that's idle.

the game permanently registers my controller's input, so even when it's being mapped to my keyboard, it still registers the default controller mapping's inputs. Pressing up therefore moves my cursor up twice in menus. Not so good.

for some reason still registers controller input, thinks my L trigger is permanently pressed and thus endlessly spins the camera.

Oh those do sound very annoying, I can see why you'd want the option to turn controller input off... I'll keep that in mind when adding controller support for my games!

it can't be such an outlandish consideration to have a simple on/off toggle for input methods to let us also pick the input method and avoid almost comical incidents like permanently spinning cameras.

I completely agree, it's clear that having the option to disable an input is beneficial. But wouldn't the best approach be an option to disable it in settings, rather than prompting them on startup? The majority of players might be mildly bothered by having to select an input source each time they play. They might wonder why it wasn't detected automatically, perhaps even thinking that it's bad craftsman ship (blissfully unaware of the true reason for this decision).

 

[TsukaYuriko]

I like how this turned from "how to do input method detection" to "user-friendly ways to handle input method detection and selection".

I completely agree, it's clear that having the option to disable an input is beneficial. But wouldn't the best approach be an option to disable it in settings, rather than prompting them on startup?

There's another pitfall here. Technically, I'd say this is a good idea for all the reasons you mentioned while also giving them the option to change it if the need arises... if they can get to the settings screen in the first place, that is.

Touhou 12.3 (or was it 13.5? Long time ago...) has a settings menu where you can freely map and unmap keyboard and controller controls - including mapping them to nothing - but the game thinking that I'm permanently holding up on my controller didn't exactly let me select the Settings option from the main menu without turning the whole ordeal into a boss battle against a slot machine.

... and even when I did manage to select it and fight my way to the controller bindings, I couldn't unbind them because the game asks you to press the keys to map in a specific order rapid fire dating-style, so it just mapped everything to "Controller Up", including Confirm, which then confirmed the settings and - on top of moving the menu cursor all over the place - proceeded to also wildly spam Confirm/Cancel at will after returning to the previous menu. Party time.

Unplugging it to unmap the controller controls did the trick, but oof. Took me a while to figure out what the issue even was. This was the game that made me start instantly suspecting controllers whenever games start to exhibit signs of "something wrong"... such as an endlessly scrolling menu, permanently rotating cameras, or the main character being a bit too motivated to hop all over the place.


My main point is that there is no single standard regarding how stuff like this is mapped, so you'll almost inevitably run into a case where your code that works fine for 99% of common controllers doesn't work as you expect for the 1%. Hiding the only way to escape this madness behind something that expects input to work as expected while you basically have the controller equivalent of a drunk sailor is a recipe for disaster.

The majority of players might be mildly bothered by having to select an input source each time they play. They might wonder why it wasn't detected automatically, perhaps even thinking that it's bad craftsman ship (blissfully unaware of the true reason for this decision).

True that! Maybe not display it every time, but a "first run" setup which is then written to a file and loaded on subsequent runs (as players are unlikely to require changing which input methods to use often) wouldn't bother me too much. I get language and resolution prompts quite frequently when playing games, usually only on the first run, and I've never heard of anyone being bothered by that. I prefer that by a long shot over it defaulting to German when I spend 95% of the day speaking English... or, in this case, game controls engaging in wanton ransacking.

Hence the idea of having the option, but (solely or additionally?) in the form of a setting in a config file - doesn't require any interaction with the game, and while it is still a bit inconvenient for affected players, at least there is a solution in the worst-case scenario (provided that it's documented well and they can find it). I'll take either of those over either of the examples I brought up, and those are just the tip of this at times hilarious and at other times frustrating iceberg.


Maybe I should just ditch this one specific controller I somehow managed to get attached to and get a different one... might make my life easier in the long run. I do realize I'm kinda asking for problems by using a DInput controller when XInput is the current de facto standard, but...

 

[Pelican Police]

I like how this turned from "how to do input method detection" to "user-friendly ways to handle input method detection and selection".

Me too, I think it's important to ensure that the solution is user friendly. Isn't that at the core of this discussion anyway? OP wanted to make their game more user friendly by showing a custom cursor at the appropriate moment?

or the main character being a bit too motivated to hop all over the place.

I can only imagine the relief / confusion when playing it on someone else's computer, experiencing the game how it was actually supposed to be played and not with a special action enabled constantly.

it just mapped everything to "Controller Up", including Confirm, which then confirmed the settings and - on top of moving the menu cursor all over the place - proceeded to also wildly spam Confirm/Cancel at will after returning to the previous menu. Party time.

This sounds like a videogamedunkey video haha

if they can get to the settings screen in the first place, that is.

Hiding the only way to escape this madness behind something that expects input to work as expected while you basically have the controller equivalent of a drunk sailor is a recipe for disaster.

Very true, but even if you have the initial "which input do you want to use" screen on first boot, that accepts all input, if the up key is spamming, then you won't be able to use this menu either?

I get language and resolution prompts quite frequently when playing games, usually only on the first run, and I've never heard of anyone being bothered by that.

That's a great point, I have never been bothered by these either. If anything I'm excited by it because it's part of the "new game" experience, because as you said, it only asks once. But input is more situational than language. Most people will not want to change the language after setting it, but it's very possible they may want to switch between controller / keyboard (playing in bed vs at desk), and could be frustrated by the game not allowing for both and needing to change it each time (which would mean getting up out of bed to switch it to controller, using the mouse. Which might make them grumpy for the rest of the day ).

Maybe I should just ditch this one specific controller

I didn't want to suggest this, as it seems you're very attached lol. But you can guarantee there's someone else out there using one too, so it's worth thinking about.

a setting in a config file - doesn't require any interaction with the game, and while it is still a bit inconvenient for affected players, at least there is a solution in the worst-case scenario (provided that it's documented well and they can find it).

Well if they ask on the game's forum, they will be delighted to be informed that the developer has thought of them and has a solution to hand!

 

[Jaan]

Hi Everyone.

This has been a great discussion. I've enjoyed reading about preferences and pitfalls. Good game design, intelligent ideas and quality of life are essential and need to be taught early. I'm a novice programmer (it's a hobby) so getting it right from the start is good!

I like how this turned from "how to do input method detection" to "user-friendly ways to handle input method detection and selection".

That's good! If it can't be accomplished through code then it needs to be through design.

So my solution is as follows:
My original idea was to have touch, mouse and controller enabled at all times, and if a touch screen was detected simply hide the mouse cursor. Moving the mouse or changing a gamepad axis would show the cursor again.

Instead I will have a simple toggle on the main menu that can hide/show the cursor and I'll use an ini file to save it's last state.

When in-game I'll need to think a bit more. There is no cursor anywhere, changing x/y by any method moves the character. I got excited with all the touch inputs and the pause icon - because of no cursor - is touch only. I could use keyboard (and will) but the game is designed for my three year old so touch input works well. The pause icon is in top right corner, so I'm thinking of limiting x movement to a bit less than screen width, and once device_mouse_x() is within a region at the right side of the screen, display the cursor and have the pause icon and a cursor toggle slide out.

For this game that should work. You can't die. There's a mermaid that swims and pops bubbles, and there are modes where bubbles have alphabet letters in them, another with simple words. You get rewarded with happy sounds, giggles and animations.