Does the aspect ration in the editor effect movement caused by transform.position changes to velocity and also timers like in Time.deltatime or Time.framecount?
If I’m making a 2d game to be played on a console or PC screen, should I develop and test in free aspect to account for different screen sizes?
The reason I’m asking is because I have a 2d platform game that I have fine tuned my movements using timers and velocity changes to the players transform. But every now and again , without any code changes, when I’m play testing the player will jump higher then normal or move faster or slower. This means I have to retune all my variables again. I thought this may have been down to me switching my aspect ration by mistake, so I kept it steady at one setting. However, after seen this happen again today, I have switched through all ratios during play testing and my players movement is slightly out tuned. I would expect that if I switched ratios, switching back to the original would reset it.
I can see aspect ration does play a part in my tuning, but I don’t understand where these random changes come from. Is it my monitor, is it something in unity I’m not getting or is it a bug?
If you use physics and you do ANYTHING with the physics in Update() or LateUpdate(), you will get irregular behavior. Only use FixedUpdate() for physics transactions.
The total world play area will be different in different aspect ratios, as the camera is default tied to vertical size mapping to two times the field of view. See orthographicSize and/or fieldOfView for more.
Is it ok to start timers and read timers in update and grab inputs from the controls? I usually find missing inputs when I call my movement methods in FixedUpdate
It seems like my aspect ration is not the issue here but how design the relationship between between grabbing inputs from controller and performing movement?
Yes, definitely grab inputs in Update()… it even says so in the docs, particularly for the “edge trigger” inputs, the KeyDown and ButtonDown transitions, otherwise you will miss them.
in Update():
if (Input.GetKeyDown( key)) DoThing = true;
in FixedUpdate():
if (DoThing)
{
DoThing = false; // consume
// now do the thing
}
I don’t know enough about your game to agree or disagree. If your game is tied to lateral movement mostly and you want the player to be able to see X seconds of motion ahead of him laterally, you do need to make some computations to arrive at the proper camera orthographicSize to get that to happen. Those computations look something like:
// how much vertical the camera sees in the world:
float WorldVerticalViewSize = camera.orthographicSize * 2;
// how much horizontal the camera sees:
float WorldHorizontalViewSize = (Screen.width * WorldVerticalViewSize) / Screen.height;
So from those you can back-compute how big to make your orthoSize if lateral size of world is your most-critical variable for player experience. But obviously it WILL impact your vertical view!
Another fix is to present your screen in a fixed aspect and have black bars at the edges or top / bottom depending on the user screen. This is called letterboxing. You can do this with overlaid black UI, or with camera rect.
I refactored a bunch of my code, I’m doing pretty much what you said above, grab inputs in Update and apply them in FixedUpdate. I still see some irregularity when I switch to different aspects and my jumps have different heights. The difference in jump height isn’t large but its an indication I’m doing something wrong.
This is how I move my player in FixedUpdate: rb2d.velocity = new Vector2(sppedX, speedY);
I am trying to create a controlled movement, something like Mario or Celeste where I can ascend at a certain rate, hang and then descend. The values for speedY for example are calculated by determining how many frames this part of the jump should be and what value of gravity should be applied. I am ignoring the RidgedBody2D gravity, which is always zero and using my own, a constant downward force.
I am using a RidgedBody2D because it does a lot of collision detection for me for free, like not falling through the ground and detecting enemy collisions.
Am I wrong to be using a RidgedBody2D in this scenario, or should I just use my own colliders and triggers with Transforms.positions ?
I think I fixed my issue.
I did the changes you suggested but I still had the issue with inconsistent jumps. So far this seems to work.
In order to calculate the steps in my jump I was counting frames in Update or FixedUpdate. This was where my inaccuracies were coming from. For example I would assign 10 frames for the assent 3 for the hover and expect to take 2 frames to descend. This flowed nice but was giving me irregular jump heights some of the time. When I started outputting the height I was getting plus the amount of frames passing I could see the max height I was reaching was not always the same and the frame count was usually different in some small way.
I stopped tracking frames and started counting Time.fixeddeltatime in FixedUpdate.I think this is more regular interval and its fixed to the fps of my game. Basically instead of saying ascend for 10 frames I multiply 10 by Time.fixeddeltatime to give me something like .2.
Now I can just track the sum of Time.fixeddeltatime until they get to .2. So far my tests are showing consistency in height over the different Aspect ratios.