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.
2 Likes
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.
1 Like
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:
using UnityEngine;
public class MyScript : MonoBehaviour
{
private void Update()
{
if (Application.isMobilePlatform)
{
CheckTouchInput();
}
else if (Input.mousePresent)
{
CheckMouseInput();
}
}
private void CheckTouchInput()
{
if (Input.touchCount > 0)
{
if (Input.touches[0].phase == TouchPhase.Began)
{
// Do your stuff
}
}
}
private void CheckMouseInput()
{
if (Input.GetMouseButtonDown(0))
{
// Do your stuff
}
}
}
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
1 Like
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).
1 Like
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.