Single sprite with different animations vs multiple sprites

0 favourites
  • 15 posts
From the Asset Store
Adjusting the game screen for different resolutions (Letterbox scale)
  • Which method is better to use ?

    • one single sprite with different animations and all the behaviors (activated only the needed ones)
    • multiple sprites (each with only one animation) and the behaviors needed

    In other words:

    Sprite 1 (animation 1 out of 4 // 1 behavior activated // 3 behaviors deactivated)

    Sprite 1 (animation 2 out of 4 // 2 behaviors activated // 2 behaviors deactivated)

    Sprite 1 (animation 3 out of 4 // 3 behaviors activated // 1 behavior deactivated)

    Sprite 1 (animation 4 out of 4 // 4 behaviors activated // 0 behaviors deactivated)

    VS

    Sprite 1 (1 animation // 1 behavior (activated))

    Sprite 2 (1 animation // 2 behaviors (all activated))

    Sprite 3 (1 animation // 3 behaviors (all activated))

    Sprite 4 (1 animation // 4 behaviors (all activated))

    The game will be for mobiles, so I want to squeeze all the performance I can get (and yeah, I know about https://www.scirra.com/blog/83/optimisa ... -your-time )

    I'm asking this because I noticed that the animations of a single object are exported in one image, while animations for different objects are exported in multiple image files.

    Also, I have another 2 small questions:

    Creating and destroying objects (one at a time) can create junk memory or some slowness ?

    Creating the level object by object at the start of the layout from a .json file will have an impact over the performance ?

  • Anyone ?

  • I want to know this too please!

  • The first one is better.

  • I prefer "multiple sprites". Because that

    1. images would be loaded together for each sprite. If place all images in one sprite, they all will be loaded at the same time.

    2. "multiple sprites" is easy to manage in editor.

  • Top one. It's worse to manage, however it's mandatory for performance. Each different sprite object is a different packed draw call. WebGL draws in batches based on the texturemap created by C2. Each Sprite get's a different texturemap. If for any reason you go from map A, to map B then the system needs to unload mapA then load mapB. Now that's fine. however what happens if your doing lot's of different layering with different texture maps. That means WebGL will go from

    ABABABABABAB

    which means 12 draw calls here. that's low of course, but think abuot many objects like bullets.

    where as if you use a single sprite then you just get

    AAAAAAAAAAAAA

    that's one draw call.

    of course if you layer properly you can do

    AAAAAABBBBBB

    and run on 2 draw calls. But now management of layering is on you

    Of course you need watch things like 2048x2048 is the max texture size in the safe zone of devices.

    top one is better

  • jayderyu

    From what I understand, draw calls are made only for visible objects ... So I can make the logic of my game using more invisible objects and use only 1 sprite with all the animations for the visuals.

    Can you explain me more about "management of layering" ... How can I measure the draw calls to be sure I am in the "safe zone" ?

    Also can you answer me my other 2 questions:

    Creating and destroying objects (one at a time) can create junk memory or some slowness ?

    Creating the level object by object at the start of the layout from a .json file will have an impact over the performance ?

    Here is a very alpha version of the game: http://tinyurl.com/blocks191

    Thanks <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

  • rexrainbow

    Based on performance, which method would be better ?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • "From what I understand, draw calls are made only for visible objects ... So I can make the logic of my game using more invisible objects and use only 1 sprite with all the animations for the visuals."

    Yes. but that's what you were asking at the top. Which is better.

    A. Better for performance

    B. Better for object type management

  • Management would be more important than performance gain. And I did not think it would increase performance obviously.

  • My structure is the following:

    1 Sprite for the player (invisible, used only for collision) + 1 Sprite for the player's animations

    (since the player will have a lot of sprites + skins I will use a different sprite from the other objects)

    1 Sprite for the objects in the game and for enemies (invisible, used only for collision) + 1 Sprite for animations

    1 Sprite for the level's layout

    1 Sprite for the onscreen buttons/gamepad

    1 Sprite for HUD and other elements

    1 Sprite for the elements in the Main Menu

    ...etc

    While I still use several sprites for the animations, I grouped them and pick them using a variable named "ID".

    Just to make sure, draw calls are made every tick, not just only when a sprite changes frame/animation ?

  • Depends. In my experience its hassle to choose random sprite, need to use variables. So I just name my sprite animations "name" & 1, so I can switch and call them whenever I want to.

    This way you can have several walking animations for different characters etc.

  • Really interesting! Thanks for the hints!

    One question:

    • Is it really necessary to use an empty sprite and "pin" the animations? I mean, You can use the collision poligon in each frame of the animation. This way you avoid using one extra sprite + the "pin" behaviour.

    Shouldn´t this improve performance even more?

  • What I do: If I have an object that will have different looks but same mechanic (like levers, or buttons), I use one sprite with multiple animations. However if the object have a different mechanics, I use seperate objects to make it easier for myself.

  • My structure is the following:

    1 Sprite for the player (invisible, used only for collision) + 1 Sprite for the player's animations

    (since the player will have a lot of sprites + skins I will use a different sprite from the other objects)

    1 Sprite for the objects in the game and for enemies (invisible, used only for collision) + 1 Sprite for animations

    1 Sprite for the level's layout

    1 Sprite for the onscreen buttons/gamepad

    1 Sprite for HUD and other elements

    1 Sprite for the elements in the Main Menu

    ...etc

    While I still use several sprites for the animations, I grouped them and pick them using a variable named "ID".

    Just to make sure, draw calls are made every tick, not just only when a sprite changes frame/animation ?

    Shouldn't you use 'Tiled Background' for level layout?

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)