Hi guys,
I’m making a 2d game , I made everything right and the canvas is responsive for all the screens , but when I play it in a 1920x1080p monitor , the player walks and jumps very slowly , but everything works in the editor (10:9)
this is my player script :
using UnityEngine;
using UnityEngine.SceneManagement;
using System.Collections;
public class PlayerController : MonoBehaviour {
public float maxSpeed = 6f;
public float jumpForce = 980f;
public Transform groundCheck;
public LayerMask whatIsGround;
public float verticalSpeed = 4;
[HideInInspector]
public bool lookingRight = true;
bool doubleJump = false;
public GameObject Boost;
private Animator cloudanim;
public GameObject Cloud;
public GameObject gameoverground;
public Camera mycam;
private Rigidbody2D rb2d;
private Animator anim;
private bool isGrounded = false;
// Use this for initialization
void Start () {
rb2d = GetComponent<Rigidbody2D>();
anim = GetComponent<Animator>();
//cloudanim = GetComponent<Animator>();
Cloud = GameObject.Find("Cloud");
// rb2d.velocity *= mycam.orthographicSize * 1,
//cloudanim = GameObject.Find("Cloud(Clone)").GetComponent<Animator>();
}
void OnCollisionEnter2D(Collision2D collision2D) {
if (collision2D.relativeVelocity.magnitude > 20){
Boost = Instantiate(Resources.Load("Prefabs/Cloud"), transform.position, transform.rotation) as GameObject;
// cloudanim.Play("cloud");
}
}
// Update is called once per frame
void Update () {
if (Input.GetButtonDown("Jump") && (isGrounded || !doubleJump))
{
GetComponent<AudioSource> ().Play ();
rb2d.AddForce(new Vector2(0, 1080f));
rb2d.velocity *= mycam.orthographicSize * 0.11f;
if (!doubleJump && !isGrounded)
{
doubleJump = true;
Boost = Instantiate(Resources.Load("Prefabs/Cloud"), transform.position, transform.rotation) as GameObject;
// cloudanim.Play("cloud");
}
}
if (Input.GetButtonDown("Vertical") && !isGrounded)
{
rb2d.AddForce(new Vector2(0,-jumpForce));
Boost = Instantiate(Resources.Load("Prefabs/Cloud"), transform.position, transform.rotation) as GameObject;
//cloudanim.Play("cloud");
}
}
void FixedUpdate()
{
if (isGrounded)
doubleJump = false;
float hor = Input.GetAxis ("Horizontal");
anim.SetFloat ("Speed", Mathf.Abs (hor));
rb2d.velocity = new Vector2 (hor * maxSpeed, rb2d.velocity.y);
isGrounded = Physics2D.OverlapCircle (groundCheck.position, 0.15F, whatIsGround);
anim.SetBool ("IsGrounded", isGrounded);
if ((hor > 0 && !lookingRight)||(hor < 0 && lookingRight))
Flip ();
anim.SetFloat ("vSpeed", GetComponent<Rigidbody2D>().velocity.y);
}
public void Flip()
{
lookingRight = !lookingRight;
Vector3 myScale = transform.localScale;
myScale.x *= -1;
transform.localScale = myScale;
}
}
Is this also happening when you play in ‘editor fullscreen’?
I feel kinda bad for asking, but maybe due to the lower resolution in editor mode it runs smoothly, and full screen build mode simply eats up too much GPU, thus slowing framerates and with that the fluidity of movement. Check your task manager performance stats in editor mode as well as in build mode.
in the editor , if I put something lower than 1920p it works perfectly , but if it’s 1920p or more , it’s slow (in fullscreen or not , it’s the samething) , I have a powerfull Nvidia gpu , an i7 9th generation cpu and 16gb of ram, and my friend also tested the game , it’s the samething , the problem is on 1920x1080p displays
The thing is, your specs pretty much dont matter. You can fully load any CPU with just a couple lines of code, if you so desired. And you can do similar things with the GPU, using expensive effects, having too many drawcalls, …, most of which scale over resolution. A game that runs well (let’s say 60 FPS) on 1080p, wont be anywhere close to playable on 4K. So if a lower resolution runs well, but increasing the resolution results in slowed framerates, then this seems like a performance problem, not a build problem. How much FPS do you have in editor mode with your ‘runs well’ resolution?
Is that framerate CPU bound or GPU bound, ie how long do main thread and render thread take? The proper way to debug performance problems is through the Unity Profiler, but for now the Stats window should tell us enough.
Also, use the maximize on play and see how that changes things.
First of all, you originally said its the movement that appears to be slower, which doesn’t necessarily mean your game runs slower in general. That’s the first thing to clarify.
Second of all, just by looking at the code you’ve posted, it’s to be expected that there are lots of things that require revision. You do things in the physics cycle that you shouldn’t be doing there.
One of those things are input queries, which stands out in this context, as you’re controlling your movement, velocity and animations with it. There’s no guarantee physics and normal updates run in a 1:1 ratio, which means that you might miss Input and reset your movement values every now and then. The result may be inconsistent movement.
in 16:9 it works perfectly , but I added a custom resolution : 1920x1080 because I’m building for windows and it’s slow , I build the game and exported it to windows platform and it’s the samething in 1920x1080 displays
NO DON’T
Try sharing the project so others can locate bugs or at least keep a backup. Even me, when I was first starting out, I had many mistakes (even though I still make them), but it is unwise to do so
Perhaps try to answer the question whether it’s an actual performance thing or a bug in your code. You never mentioned how you determined that it runs actually slower.
I already posted some hints as to why you might see inconsistent behaviour. But that’d all guessing and if you’re not willing to investigate a little more noone will be able to help.
You should modify physics-related values in FixedUpdate instead of Update (your input-handling should remain in Update in case of the old input manager).
This is what I don’t understand. Could you please describe what do you want to achieve with this?
Same thing, move to FixedUpdate.
You shouldn’t handle input in FixedUpdate in the old Input manager. You can lose input this way. Move it to Update.
You shouldn’t forget that by default the FixedUpdate only runs on 50Hz. If you don’t have a target framerate, your application is running on as many frames as possible. So you have N Updates while you have only 50 FixedUpdates per seconds.
