After clamping my block to the left/right world units, I was playing with bouncing the ball and noticed an issue. If my mouse cursor is at the level of the brick, give or take a few world units, it works as expected. But if my mouse is halfway up the game screen, and exits to the left, the paddle will suddenly jump to the right of the screen.
On investigating, it seems that when the mouse cursor is out of the game area, it’s wrapping the X count. Just to the left of the zero position, it starts reporting a much higher number (622 in my current test) and counting down as you move the cursor left.
I get that this is outside of the game space, and I know there are other methods for tracking relative mouse movement rather than asking for the position. However, what I want to know is why I’m seeing this behaviour. First off, I would expect that if you went off the left of the screen it would stay at zero. Second, I would expect the behaviour to be consistent across the y-space. What’s going on here?
You bet. Note that my Debug test was to examine the mousePosition and it’s that value that is jumping. What I’m saying is that I’m pretty confident my math isn’t the issue, because it’s the input value to it that is busted.
using UnityEngine;
using System.Collections;
public class Paddle : MonoBehaviour {
// Use this for initialization
void Start () {
}
// Update is called once per frame
void Update () {
int widthUnits = 16;
Debug.Log(Input.mousePosition.x);
float mouseX = Input.mousePosition.x / Screen.width * widthUnits;
mouseX = Mathf.Clamp(mouseX, 0.5f, 15.5f);
Vector3 paddlePos = new Vector3(mouseX, this.transform.position.y, 0.0f);
this.transform.position = (paddlePos);
}
}
I don’t have a clue why this is happening either, but usually it is better to only update a value when we want to change it rather than always update it either way (I have experienced some issues while updating values when I didn’t need to), probably there are some equations within the mouseposition method that is returning a null value when you move your mouse outside the game space and consequently makes the method return an unexpected value, I don’t know. But I think that you could put it inside an if statement in order to check if it is inside the game space or not and update the mouseX value:
float mouseX = 8; //middle of the world space
int widthUnits = 16; //I feel that it is better to initialize it outside the update since you don't need to update this value every frame
void Update () {
Debug.Log(Input.mousePosition.x);
if (Input.mousePosition.x / Screen.width * widthUnits > 0.5f && Input.mousePosition.x / Screen.width * widthUnits < 15.5f) // updates the value of mouseX if it is within the screen
{
mouseX = Input.mousePosition.x / Screen.width * widthUnits;
}
//Don't require else statement neither a mathf.clamp in this example, it will just keep the last value of mouseX if you are outside the screen
Vector3 paddlePos = new Vector3(mouseX, this.transform.position.y, 0.0f);
this.transform.position = (paddlePos);
}
I haven’t tried it, but I think that this should work
Sadly, that doesn’t work. The problem is that Input.mousePosition.x is coming back with the incorrect value. It reports a valid, on-screen value, despite being visibly out of the game. So, for example, if my cursor is about halfway up, but just to the left of zero, it will return, say, 622 for the x position, when it should be about -20 based on what you can see.
Since the input data is incorrect, no amount of double-checking it will correct the issue. I’m trying to figure out why Input.mousePosition.x is incorrect.
I had seen that too. I’m almost certain that other issue is the camera transform. I’ve wondered if I have some sort of issue with the camera as well.
I just did another test and it seems the issue goes away if the game window is on my middle monitor (I have a triple monitor setup). So this issue may be beyond the scope of the course, but I’d still love to know what’s going on.
It works just fine on the right side. Once the mouse exits the play area it remains at a high value. Note that it works off the left side as well, when the mouse is in the lower fifth of the play area (see the animated .gif I posted in the first part of the this thread).
