Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

How to display sprite in left and right bottom of the screen?

Discussion in '2D' started by Asim Arif, Jul 21, 2014.

  1. Asim Arif

    Asim Arif

    Joined:
    Nov 6, 2012
    Posts:
    22
    Hi,
    I need to display a sprite on the right and left bottom of the screen and this should work on all screen size devices. Can someone please suggest me how to do this?

    For more, please see the attached image.

    Thanks
     

    Attached Files:

  2. Pyrian

    Pyrian

    Joined:
    Mar 27, 2014
    Posts:
    301
    Here's a snippet of code I use in my camera's LateUpdate to keep a couple sprites on the left and right sides respectively. Keep in mind that I selected my pivot points on the Sprites to work with this (the LeftArrow has a Left-Bottom pivot, the RightArrow has a Right-Bottom pivot).

    Code (csharp):
    1.  // Touch arrows
    2.  float OrthoWidth = camera.orthographicSize * camera.aspect;
    3.  LeftArrow.transform.position = new Vector3 (transform.localPosition.x - OrthoWidth, 0.0F, 0.0F);
    4.  RightArrow.transform.position = new Vector3 (transform.localPosition.x + OrthoWidth, 0.0F, 0.0F);
     
    dginovker likes this.
  3. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    9,042
    Why would you put that in LateUpdate? Add things to updates that don't actually change adds overhead.
     
  4. Pyrian

    Pyrian

    Joined:
    Mar 27, 2014
    Posts:
    301
    Because, I quote, "a follow camera should always be implemented in LateUpdate" (source).
     
  5. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    9,042
    But what does a follow camera have to do with sprites? A follow camera by definition has to update it's location every frame because it is following something. If you are just setting sprite locations there is no need to update them every frame. Once you set the position, they won't move.
     
  6. Pyrian

    Pyrian

    Joined:
    Mar 27, 2014
    Posts:
    301
    The camera determines where Sprites appear with respect to the screen, so "everything", really.

    If you set a Sprite to appear in the bottom left corner of the screen, it will remain in that position only insofar as your camera never moves. You could, in fact, use my code once in Start - so long as you never move your camera. Now, in my game, this would be entirely inadequate, because I am in fact using a type of follow camera, so once you moved, the Sprites assigned to the left and right sides of the screen would get left behind.

    I don't know whether Asim Arif is moving his camera or not, but it's worth noting that the solution I posted would work either way with essentially negligible overhead.
     
  7. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    9,042
    Ideally, if you are using binding contents to the screen space, you would use a separate camera. But if you don't want to use a separate camera, then just parent the sprites to the camera, rather than implicitly moving them every frame to keep up.

    It may seem negligible, but it is unnecessary. The little stuff adds up.
     
  8. Vitor_r

    Vitor_r

    Joined:
    May 23, 2013
    Posts:
    93
    zombiegorilla, a second camera won't cause some performance issues? Or it would be negligible like u said?
     
  9. Pyrian

    Pyrian

    Joined:
    Mar 27, 2014
    Posts:
    301
    Why is that ideal? It seems like more overhead to me, rather than less.

    (You've got implicit and explicit reversed.) I'm not sure there's any performance distinction, here? And various prefab considerations leave me highly reluctant to parent my HUD to the camera. Also, I'd have to detect (or prevent) changes to the aspect ratio, anyway.

    We're building 2D games in 2014. Every performance snag I've seen in this setting was never the little stuff adding up, it was the big stuff, it was things that would cause a performance problem without anything else going on in the project, like that guy who piled 80 Rigidbody2D's into a single heap, all of them running OnCollisionStay2D's. An implicit versus explicit position set was not going to help him.
     
  10. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    9,042
    For simply anchoring, using an additional camera would more overhead. Performance issues, no not really. It is very common to use multiple cameras, especially for UI. Depending on your scene though, it may be less, especially if you have a lot of things going on. But generally speaking it's a solid solution.
     
  11. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    9,042
    If you have a hud, text etc... typical ui stuff, putting on a separate camera is a better solution for many reasons. You aren't sorting that content against the whole scene during render, it isn't moving, etc. But if you don't have a moving camera and/or are in 2d single camera can work just as well. It will always depend on the exact situation, but for most cases it is good solution both for performance and organization.

    Whoops, my bad.

    I'm not sure why you would be reluctant, changing parents is a single line, no need to structure it in prefabs. Aspect ratios rarely, if ever, change from start up. The notable exception would be if you allow rotation on a device. Web won't change, and desktop may change if the use manually changes, but even then, it won't really be in the middle of game play. In either event, If you do anticipate that a ratio change may happen, the cleaner approach is create an event that objects can subscribe to that will notify them to that the screen has changed. That way you are only making modification when they are needed, not 30-60 times a second.

    When you build larger projects or a project grows or becomes more complex, the little things definitely add up. Every little bit will count. Because you haven't seen a situation where a bunch of unnecessary updates impacted performance isn't a reason to design inefficiently. Good practice is good practice. Running a MB update for something that doesn't need to be updated is unnecessary. And even if a project is simple enough that it would have no visible impact, it is good practice to do things in a more proper way. (and more importantly, not to suggest to more novice users bad practices).