Don't know how to optimize more than that

Hi, i am developing for mobile.
My game is not that big but it feels like it’s not so smooth either.
I lower my texture to normal size.
I reduce the sound quality and make it compressed.
My scripts are well written i guess, i almost don’t use Update function and if i do, i am not using
expensive functions there.
The quality of the game set to lowest.
This is a 2D game.
I have alot of bricks ( approximatley 100) per scene. All are static objects.
And few lightpoints with culling mask that cover the bricks and the background.


What else can i do???
Please help me.
Take a look on the game:

Maybe the lights are too much for mobile?

Don’t guess: use the profiler.

1 Like

Have you tried running the Profiler to see where the overhead is? You can also do profiling while running a build on the mobile device.

I feel like i don’t understand nothing from the profiler :confused:
Can you help me analyze it?

3491255--277991--profiler.PNG

It looks like the large majority of the time is spent waiting for VSync, which is not really an issue.

Agreed with methos5k, everything looks good. Is that connected to the mobile version? Could you elaborate on what you mean by “it doesn’t feel smooth”, maybe you’re doing other things incorrectly like not using delta time or using a very low fixed timestep interval.

Hmm, I am using the profiler on the pc.
It feels less smooth in stage that there are more bricks and lights.
I’ll show u where i use delta time and fixed update maybe it is the problem.
FixedUpdate:

    public void Moves()
    {
        if (Manager.WhosPlaying == WhoAmI)
        {
            transform.position = new Vector3(transform.position.x + MoveSpeed * dirAcc * Time.deltaTime, transform.position.y, transform.position.z);
        }
    }

And this one is the camera script.

    void FixedUpdate () {
        transform.position = Vector3.Lerp(transform.position, Follow.position + Offset, Speed * Time.deltaTime);

    }

I thought about something tell me if it’s a good idea.
Should i make a sprite of 20 bricks instead one?
Maybe it would be better because the use of the materials.
And i changed the material to mobile diffuse for the bricks but the i stayed with the same material for Background and players.

Any good idea for background instead of a big picture?

Any idea?
And btw, why the Size of unity files are 20 mb on minimum?
I heard i can low it down to 10mb, why it is not 10 on default?

You should profile a build on the target platform, rather than in the editor, because the performance characteristics between the two are often significantly different.

Here are a few resources that should help you to get started with the Unity Profiler.

Learn how to diagnose common performance problems and optimize your projects:
https://unity3d.com/learn/tutorials/topics/performance-optimization

Introduction to the Profiler

https://www.youtube.com/watch?v=sBpXiJ9G3OY

Unite Europe 2017 - Practical guide to profiling tools in Unity

https://www.youtube.com/watch?v=OSlOwJP8Z14

Unite Europe 2017 - Performance optimization for beginners

https://www.youtube.com/watch?v=1e5WY2qf600

Thanks for the help.
But i need to understand how can that is even possible that a little game does not work smooth and a big game of a big company does.
So lets say my problem is the shaders, i won’t use shaders? i’ll always work with low texture and low quality?
It’s weird. There has to be a solution instead of just profiling.

Don’t move the cam in the physics update. You might be grabbing wrong information of your follow transform.
Move it in Update or even better, move it in LateUpdate when everything else has been moved / calculated, as your camera’s transform information may rely on these values.

1 Like

Guys the Camera move just fine, everything works fine with the movement.
The thing is the game it self not working fine. Sometimes it does but when the scene becoming heavier the game running slower.

It’s still something you should fix. It doesn’t make alot of sense to move the camera in the physics update and you’re potentially grabbing outdated information.
I’m not saying this is the evil part in your particular case, but it’s certainly something one should keep in mind. Just put camera logic in LateUpdate to avoid lagging behind / having jittery/shaky effects.

Other than that, if you’re not just having a jittery camera and instead, you’re facing actual performance problems, you have to provide a little more information.

1 Like

I don’t have any idea about the smaller size, sorry.

However, for the not running well in general, I can only imagine as others have pointed out is that you should profile it on your target device, and when it’s “heavier”. If then you don’t understand what the profiler says, ask for more help with more information provided. The last screenshot showed that the device had plenty of “free time”. :slight_smile:

But how can i use LateUpdate when i use FixedUpdate on movements? I tryed it, just look awful.

What kind of movements? Physics-based or just some normal non-physics movements that you apply in FixedUpdate?

How and where do you move the object that’s meant to be followed by the camera?

You got good advice already, not much to add.

Likely you have one of the following issues:

  • wrong logic (the issue you see is produced by your code)
  • lag = too much time per frame (the issue you see is produced by your code taking too much time)

To rule out lag

  • use a simple frame rate counter
  • use the profiler from the native ide (ie Xcode) to Check frame time
  • use the unity profiler in a dev build

I use transform.position to move the player.
I am not using rb if that what you asked.
So if i understand you right, it is better for me to move the movement to late update because i don’t use physics for that?

I think with movement that modifies the transform directly, it’s better suited to be done in Update, and the Camera in LateUpdate, as mentioned.

Personally, I found that if I move an object in FixedUpdate (though with physics, mind you), that I also want to move my camera in FixedUpdate.

Since you aren’t using physics, I think you’d be better off re-arranging it.