OnMouseDown Stops working in mobile build when Scripting backend is converted to IL2CPP

Whenever i change Scripting Back end from Mono to IL2CPP My Game build doesn't respond to OnMouseDown Events it works fine when build with Mono. I have tried many things but nothing seems to work.
I Also get this warning : Game scripts or other custom code contains OnMouse_ event handlers. Presence of such handlers might impact performance on handheld devices.

 

I suspect you experiencing issues with code stripping. Disable it in build settings completely and check again.

This handlers are a little bit slower than using input system interfaces and events. You may ignore it as slowdown is insignificant.

 

Thanks you It worked!!!
Unchecking Player Setting>> Other Setting >>Strip Engine code worked for me .
I hope it will not cause any issue in the release build.

 

This will cause slightly larger build size. Compare both build sizes to check if it is an issue for you or not.

 

The answer is you should not be using OnMouse_ event handlers in a mobile game, you should rewrite those methods to handle Touch.

 

What if game is crossplatform? Unity is cross platform engine, there's an option to handle touches as mouse for that in the API

 

Then you should write your own methods to handle pointer events. OnMouseDown, OnMouseUp and the likes is meant to be used to handle mouse events, which is kinda hard on mobile games.

Unity provides an internal workaround, but as the warning states, this could have a negative impact on the performance of your mobile game.

It's also not that difficult to write custom methods to handle input events that work cross platform.
A quick search on the internet yields a multitude of options to implement cross platform input, but for your convenience I'll provide an example that should do the trick for the OP's original question:

Code (CSharp):

1. using UnityEngine;
2.  
3. public class MyScript : MonoBehaviour
4. {
5.     private void Update()
6.     {
7.         if (Application.isMobilePlatform)
8.         {
9.             CheckTouchInput();
10.         }
11.         else if (Input.mousePresent)
12.         {
13.             CheckMouseInput();
14.         }
15.     }
16.  
17.     private void CheckTouchInput()
18.     {
19.         if (Input.touchCount > 0)
20.         {
21.             if (Input.touches[0].phase == TouchPhase.Began)
22.             {
23.                 // Do your stuff
24.             }
25.         }
26.     }
27.  
28.     private void CheckMouseInput()
29.     {
30.         if (Input.GetMouseButtonDown(0))
31.         {
32.             // Do your stuff
33.         }
34.     }
35. }

 

I'd prefer to use existing solution provided with engine even if it is "workaround" (no, it is not, just input redirection flag, pretty normal thing to redirect data in programs overall, actually to represent this as that is well know concept for all programmers). During my whole career with Unity I've used construction you suggested only twice, because there was very touch specific input handling in mobile version of that games not possible to represent with mouse actions. And while it is clear for me about performance impact, this impact is very insignificant. It is just one sendmessage during a frame, may be two. This is kind of optimization like loop unrolling or inverse byte order for sending bunch of floats over the network or avoiding virtual method calls. If I make my rendering issue 1 draw call less, it will give me much more performance ^)

 

not sure about this, but seeing that OnMouseDown does not work anymore in IL2CPP, I think it means support is dropped for mouse events on mobile platforms on that scripting backend. This thread might need an intervention from someone who knows this for a fact...?

 

Probably this is code stripping in build issue. Disable it completely and check again.

 

Solution

 

So you guys rather have a bigger build size and performance impact over writing a bit of code to handle touch input?

I was under the impression that answering a question in the SCRIPTING section would revolve around ... euhm... scripting? instead of providing a workaround like disabling engine code stripping for your solution to work.

 

Well, if you have 2gb assets you just don't care about 45 mb engine. Again, just by modifying texture or audio compression settings I will get much more decrease in build sizes than by stripping unused engine code. Also assembly/engine stripping is configurable so you can have both stripping and old input system, if you want to. Always check the product value of the work before you do it and prioritize tasks by estimated product value and implementation costs, that's how I do.

Let's back to the numbers. That performance decrease is less than 1% anyway and when we talking about build size, we're talking about probably dozen megabytes of stripped code from build. It's like storing and rendering one texture in terms of size and performance. If I will work on project where this numbers will matter I gues I'l; turn to unity tiny or even some native engines.

The only thing ever made me write the piece of code you suggested were the project requirements what required me to do so because of touch input specific actions not possible to represent with mouse actions. Otherwise, I don't see the point of doing it.

 

"On top of native touch support Unity iOS
/Android provides a mouse simulation. You can use mouse functionality from the standard Inputclass. Note that iOS/Android devices are designed to support multiple finger touch. Using the mouse functionality will support just a single finger touch. Also, finger touch on mobile devices can move from one area to another with no movement between them. Mouse simulation on mobile devices will provide movement, so is very different compared to touch input. The recommendation is to use the mouse simulation during early development but to use touch input as soon as possible."

Found on Unity docs here

 

That's theory. The practice differs. In practice you do only 1 thing at a time and you should choose carefully in order not to waste your time.

 

in practice... you should never use mouse input on mobile

 

Yes, but it's only cross platform to a point, and once you've reached that point it's up to the developer to use the correct API.

For the duplicate of this thread that was in General Discussion I linked an easy to use solution for handling touch written by @passerbycmc that provides nearly equivalent magic methods for touch (eg OnMouseDown becomes OnTouchDown).

https://forum.unity.com/threads/an-equivalent-of-onmouseup-down-for-touch.315447/#post-2049555

 

Yes, I'm fully aware you can hook up devices that weren't intended to be used to a phone. Last I was aware Android's Linux kernel still shipped with ZIP drive support.

All of that is irrelevant though because at the end of the day that's not the intended use of the platform, and pushing beyond what is the intended use is your problem to deal with when it breaks. Unity won't support nonsense like that any more than Google will support it, and to be blunt any smart developer won't support it either.

 

I've looked through new unity input system and it can support probablt any controllers on any devices
And this is not such an uncommon thing in the world, there are plenty arm laptops with windows rt and androind and they may have both touch screen and touchpad/mouse controllers
Also you may connect mice and keyboard to android tv or console easily
So I believe nonsence is to force touch API only because your devices have touch screen.

 

OnMouseDown and other magic methods are powered by the old input system.

Windows RT having support is not surprising in the slightest seeing as it was launched alongside Microsoft Surface, but Android having support is a different story and the fact that there are no modern Android-based laptops available (other than bizarre hardware coming out of China) says everything that needs to be said about that.

Again it's completely irrelevant for Android because it's not the intended behaviour for the device. Just as an example Sony has a support entry for attaching a keyboard to their Android TVs and the statement is "operation isn't guaranteed". Clearly it's not intended.

https://www.sony.com/electronics/support/articles/00128141

That said both Android TV and consoles are irrelevant because you're not controlling them with touch.

What you believe doesn't matter in the slightest. You either use the game engine as it's intended and receive support if something goes wrong, use the game engine as it's not intended and not receive support, or choose a different game engine entirely. Hopefully the next one will be more in tune with the way you want to believe things work.

 

So what? You said unity wont, i replied unity will and already do.

What about https://www.samsung.com/us/mobile/tablets/galaxy-book/ there are many others too from HP and Lenovo, Microsoft recently announced new arm windows, so there are more expected.

Sony can not guarantee any keyboard from any manufacturer to work with their tv and that's completely normal. There are a lot of input devices in the market what works with some hardware or os and do not works with another. I had a mice what glitched in windows and worked okay in linux, and there are keyboards what won't work with linux. Manufacturers just don't care and Sony can't take care of this for them. You are making too big conclusions from this small and obvious fact.

This made me laught a lot. I am controlling my lg smart tv with touches. It comes in very handy especially when browsing or playing, where remote isn't comfortable to use. And I know a lot of people who do this. This is not right, according to you, but they just don't know that ^)

You sound like stereotype german, stick to instruction and do not try anything ^) Sorry fellow germans, im not supporting stereotypes. That's cleary not the creator way. I have things and use them as I want to make my players feel joy. No instruction covers this and it can't be covered with instructions.

Aside from all of that, games made your way can't be played without touchscreen, and made mine way can be played with any controller pretending to be mice. This makes install base wider and the product is overall better. And that's it.

 

I'm perfectly fine being thought of that way if the only alternative is to be someone like you who believes that their way of coding is perfectly fine when in reality everyone says it's wrong and it leads to problems down the line when the company developing the tools finally cuts off support for using the feature incorrectly.

On the other hand there are tons of instructions on what you shouldn't be doing with this game engine. I'm sorry you're not capable of understanding that. Since it's clear you're not willing to listen to anything anyone says you're now on my ignore and won't be coming off. I have no time for people like you when there are plenty of people willing to learn properly.

 

Nice! This fixed it for me!!!!!