How to "merge" sprites in defold

Hi there.

I am not sure how to solve my idea…

I like to have a sprite/GO thats just 2 or more spriteparts. Lets say we have a tank. There is the “moving-part” like the chain-tracks and the shooting part above. these could be one sprite of cause, but I like to use 2 sprites. In this way I could change the chains for example.

Sure I could use a collection, but colletions IMO are just a collection of GOs. But I dont want to waste too much gameobjects in my project.

Next could be spine. Dont know spines and never used them. Not sure if parts of a spine are changable.

Is there another way of having “couple” of sprites as one (Gameobject)?

A game object can have multiple sprites and you can change them individually (animation, hflip, vflip, scale).

You shouldn’t consider this as waste. A game object by itself is not expensive, and if it makes sense for your project to use two game objects then by all means use two!

Spine would be another good solution to your problem. You can change skin on a spine model and you can attach game objects to the bones of the model.

If the two parts are going to stay at the same location, you can just have them as separate sprite components in a game object. You can play different animations on the tracks and the turret as you see fit.

If you want to be able to move or rotate the two parts separately, you should use two game objects. You don’t need to worry about having too many game objects. Defold handles tens of thousands of game objects without breaking a sweat. Here’s a quick test with 4000 game objects, each with a sprite:

4 Likes

Hey @britzl.

Thanks for your answer. Like you may remember I am working on a strategy game. There are a lot of gameobjects (deco, units, buildings) around, so I already set up the max GO in the properties to 512 or 1024. Feels like the game starts to lag (in HTML5). I increased some of the standard-values like GUIs, GOs etc. Since that my HTML5-Test is pretty lagging - already at startup (not having tons of GOs).

So you say having more GO are not such an performance-impact? If so, I could increase the max GOs to some thousands and change the actually GO to collections with 2 or 3 GO inside. That maybe give me some more options, like turning these different GO to different angles etc. For example: a tank is moving to left, so the “driving-part” of it may rotate to driving direction. Firing (the upper part of the tank) may rotate to another direction.
Also, maybe the tank gets different tracks/chains so I could change them via script.

So collection or spine?

It is most likely not the number of game objects that cost performance but the number of draw calls, overdraw and what you do in scripts. If your game is laggy you should do some profiling to see how it is performing in these areas.

@sicher.

Thanks for the example. It felt like getting slow after increasing the max GOs in the game properties after testing an HTML5 build.

Yes, these 2 “parts” may have different rotation like I’ve postet seconds ago. Not sure which “solution” may be the best.

Thanks. Optimisations etc are already on my To-Do.
Already read about it in different threads.

I read something about the GUI-Box-node which (seems) to cost a bunch of draw-calls if there is no sprite attached.
I am using these simple box-nodes, because I thought I could reduce calls with that :smiley:

Here is my test in HTML5. It runs at full 60FPS with some time to spare.

1 Like

Note though that since each sprite is from the same atlas all 4000 are drawn in 1 draw call. There are no scripts running either.

1 Like

That means using different atlases are wasting draw-calls?
I quess I have 4 or 5… units have one, structure have one, tile-set, gui have one etc.

Already thought about joining to one atlas… maybe better.

Yes, if two sprites use two different atlases they will consume two draw calls.

How many draw calls are you at currently?

at left-bottom you can also see the grey text by myself showing just a couple of: items (GO), units (GO), structures (GO), deco like trees (GO)

/EDIT:
I got 42 draw calls…

OMG…
After opening a unit-menu…142 o.O

The menu is a dynamicly created menu based on a GUI “template” containing a 1 box-node, 1 spite, 2 text (2 fonts)
the 3 buttons around the unit are GUI boxes with sprite/graphics.
The info-box right-botton is GUI-box-node with graphic and text-node

HTML5 temporary test:

http://root.trinium.de/AbandonedForceDEMO/

Use F9/F10 for debug.

If I see the “iron”-item moving up and down I see how slow it works just from the start. normally it goes faster and smoother

/EDIT:
If you just click a unit (some squares with icons appear like moving, suicide etc) the draw-call jumps from 42 to 124 o.O

I quess there is a litte “optimisation” needed LOOOL

Back to the topic … I quess the main question was answered. Will testing which way may be the best a) 1 GO with 2 or more sprites, b) Collection with 2 or more GO or c) spines. Maybe collections will be a good way so every “part” will be a GO and together it will be a unit, structure etc. So I can change rotations etc.
Having a base with a rotating radar for example which is a collection. Or a tank with tracks facing to different angles etc.

Is it possible to deactivate a GO in a collection or changing its sprite?

Sure. Most components can be disabled, just send a “disable” message to the game object and its components will be disabled.

Yes, you can play animations on the sprites to change the graphics - as long as the animation is within the same atlas.

Ow, 142 draw calls, that’s a bit too many I’d say. I’m sure there are ways to reduce the number of draw calls to less than 20 in your game. Please read up on how the engine batches draw calls and what you can do to help the engine to reduce draw calls:
Draw calls and Defold

2 Likes

I already know how to disable etc. Just needed to know if its possible with collections.

Thanks!

Collections have no impact on a game object at all. They are a means of organizing game objects. They do not exist as a concept in runtime.

1 Like

First step (maybe interesting for beginners like me)…

ON top there is a statistic window. Used 3 atlasses in the past (units, structures, ingameGUI).
I’ve made a new atlas with all used graphics.
Changed the statistic graphics and set up just ONE atlas and changed the linked graphics of cause.

DrawCalls past: 42
DrawCalls now: 40

Sure, small result, but anyway, shows me how things take effect.
Will now change all Sprites to the new atlas.