koobas.hobune.stream
iPhone Touch detection programing difference
hi there!
i wonder if there is a difference between
if (iPhoneInput.touchCount > 0) {
touch = iPhoneInput.GetTouch(0);
pos = touch.position;
var ray : Ray = Camera.main.ScreenPointToRay(Vector3(touch.position.x, touch.position.y));
var hit : RaycastHit;
if (Physics.Raycast(ray,hit))
{...
and
if( Input.GetButtonDown("Fire1") )
{
Ray ray = Camera.main.ScreenPointToRay(Input.mousePosition);
RaycastHit hit = new RaycastHit();
if (Physics.Raycast(ray, out hit))
{...
in performance or sensibility or is it just the same at the end...
thnx!
The short answer is that they are essentially the same both in terms of speed and function although one is written explicitly for a touch interface while the other is written to access Unity's Input system. Depending on how they compile out for the target platform and hardware specific optimizations, comparing the two becomes more challenging.
Obvious differences:
- One is javascript and the other is C#. Both compile out more or less the same.
- One is checking against touch input while the other is checking against mouse input. Which might involve linking in more assemblies for the touch version, depending on how Unity is setup to compile this and what platform, etc. If they're both for a touch platform, then the Touch version is both clearer and should be more performant.
- As Eric5h5 says also, you'd want to check the touch phase for identical simulation.
Performance-wise, let's consider the instructions involved in the different steps of what you are doing:
if statement:
if(iPhoneInput.touchCount > 0) touch = iPhoneInput.GetTouch(0);
//To implement the same behaviour, you would need to use if(iPhoneInput.touchCount > 0) { touch = iPhoneInput.GetTouch(0); if(touch.phase == TouchPhase.Began) { //the rest... } }
//v.
if(Input.GetButtonDown("Fire1"))
//The touch version checks what is likely a value stored at the head of an //array already in memory. GetTouch(0) which probably has the overhead of //indexing an array of up to 5 Touch structs. Since this doesn't involve //allocating any temporary variables, it is looking at already allocated //memory and the lookup for this is quite fast if it is already loaded and //returning a reference to the object.
//For GetButtonDown, I'm not sure of the magic that Unity's input does, but //this is likely at minimum a lookup into a table of various inputs with some //function overhead and if the table is not already loaded, some extra paging. //At most, this is accessing a context interface to the hardware which is //usually slower. Then it returns a logical comparison against a value //returned. Depending on how/when/where they are stored, the table look-ups //could be comparable fast, but I as it is optimized for it, the touch version //probably outpaces the non-touch version.
//For the same functionality, the touch version would also have to access //.phase which is at least 5 bits for the enum and possibly an extra function //call+.
//The touch version should be fairly fast and if it proves false will likely //exit at less cost than the other version.
extra touch stuff:
pos = touch.position;
//.position involves accessing the memory that touch reference is pointing to //and returning a copy of the struct of 2 floats stored there - overhead the //non-touch version doesn't have both in storage and operations performed on //non-touch platforms, but for the same platform, mouse.position is essentially //doing the same thing and therefore has the same cost.
world coordinates:
//You perform two extra lookups here, creating temporary allocation of at the //least two floats if not the two of the entire struct when you already have //the same Vector2 of the position stored in the variable pos Vector3(touch.position.x, touch.position.y)
//You should try Vector3(pos.x, pos.y)
//Also, storing this Vector3 and only updating the x and y would cut the cost //of allocation in exchange for the cost of accessing the existing Vector3 //struct's floats, trading off allocation and assignment for just assignment.
//v.
Input.mousePosition
//Even in the minimal case, the touch version allocates a temporary Vector3. //Depending on the magic that Unity's input does, the input.mousePosition could //be doing something as simple as a look-up to some memory which may or may //not already be paged (with the associated overhead that entails) or it could //be actually accessing a context interface for the hardware which might be even //slower. Either way Unity likely allocates this into a temporary Vector3 also. //If the non-touch version doesn't allocate a new Vector3, this becomes overhead //that the touch version alone has, but either way the operations performed //(by you in the one case and by Unity in the other case) are generally the same //of allocating a Vector3, accessing two floating point numbers and copying them //into the Vector3. At this point, the two are likely equivalent, but the //non-touch version could be slower depending on what Input.mousePosition does.
They are probably fairly similar in terms of speed and performance, but since it should be optimized for it, despite a small amount of extra memory footprint involved in the operations, the total number of instructions and operational cost for the Touch version is likely marginally better.
It would probably be more sensible to use touch events, since there's no guarantee that "Fire1" is set to mouse button 0 (which emulates a touch event). Although you'd need to check for TouchPhase.Began to have the same behavior as GetButtonDown.
