Quick question on Visibility

Does anyone know if Sprites with Visibility hidden still renders, same as a sprite with 0 opacity.

I'm trying to locate a slight performance drop, and wondering if it could be pretty large UI elements with Visibility hidden.

Invisible means its is not rendered.

They should have little performance impact as long as they are invisible, and not moving.

You might get a drop when they are made visible however.

Btw 0 opacity means nothing to cpu performance. It's the same as 100 opacity.

Invisible means its is not rendered.

They should have little performance impact as long as they are invisible, and not moving.

You might get a drop when they are made visible however.

Btw 0 opacity means nothing to cpu performance. It's the same as 100 opacity.

Thanks, I'm trying to pinpoint something causing my draw calls to shoot high occasionally. Even when nothing is seemingly moving and nothing animated is on screen. Clean project doesn't have the problem, so I'm clueless of what it could be.

Although

I'm using a lerp quite a lot, both on objects and on the camera so maybe it could be some objects or the. Checking the Debug, i can see that they are counting down to infinitely smaller and smaller decimal points.

Might be the cause, but how do i stop the lerp from counting?

Example of lerps i'm using.

lerp(Self.X,Object.X,0.03) to get a smooth eased movement...

Maybe there is some better way to ease movements, that doesn't count to infinity?

Pick the 'self' & that 'object'

Compare 2 values .... distance(Pickedself.Y,Pickedself.Y,Object.X,Object.Y) ... > ... 2

______ lerp (dt corrected)

Pick the 'self' & that 'object'

Compare 2 values .... distance(Pickedself.Y,Pickedself.Y,Object.X,Object.Y) ... > ... 2

______ lerp (dt corrected)

I've tried that but that wasn't really an optimization (for a lot of objects) as it's constantly comparing distances every tick, which seemed to be heavier than just leaving it as it is. There must be a smarter way to limit the amount of decimals.... i don't want all those lerps running in the background all the time.

maybe...

round(self.x) ? round(object.x)

round(self.y) ? round(object.y)

So if both of their rounded X & Y positions are not equal, lerp can bring them closer until their rounded values match.

Should be less heavy to check than distance hopefully. Have to try it out when i get back home from work.

If something moves at x pixels per second then you can figure out how long it will take to get there if you know the distance there.

Add a timer behavior to change a boolean variable.

If something moves at x pixels per second then you can figure out how long it will take to get there if you know the distance there.

Add a timer behavior to change a boolean variable.

Nono, that's not really what I'm after. I just want to stop all the lerping running in the background when they are close enough to see if that's the thing causing some performance issues.

Imagine like 40-50 different objects moving subpixel amounts all the time, because lerp never stops when you use. lerp(self.x, object.x, 0.03) object keeps moving but smaller and smaller subpixel movement every tick.

It's both causing draw calls when everything is seemingly not moving, and ticking away in the background.

variable canmove=1 object set position to lerp(newpositions)

On timer set variable canmove to 0

variable canmove=1 object set position to lerp(newpositions)

On timer set variable canmove to 0

I'll try that too, I just need to stop all the subpixel movements going on.

tunepunk

Ya know what they say, measuring is the only knowledge about c2 performance.

https://www.dropbox.com/s/42m3rbnlg23cp ... .capx?dl=0

I think that the distance check wins.

I did not expect that 'moving invisible objects' has almost no effect on performance compared to 'moving visible objects'.

99Instances2Go Nice test there. Confirmed my thoughts on what was causing some slowdowns. This is crucial for me especially since I'm developing for mobile. A lot of these small little resource hogs adds up to quite a lot in the end.

So I'm gonna go over my events now and make sure I kill unnecessary stuff. All That don't need to run in the backround.

killing lerps as soon as the get close enough, and not even moving things if I don't have to. I use a lot of lerps happening of screen, things fading in and out etc on the map. I Should try kill those kind of things also. Why do i need to smoothly animate stuff not on screen right?

You should test things for yourself, but I think that unless you have hundreds of instances, checking things like animations will add very little to optimization.

I think that 'for each' is a real hog, when having to go trough a lot of objects that need a personal outcome.

So lets do something wild.

https://www.dropbox.com/s/eoxma2kzjj4r4 ... .capx?dl=0

Do you see how i avoid a 'for each' by using a container ?

newt On PC yes, but on mobile even 20+ instances can have a considerable effect from what I've noticed. Even using a simple particle emitter is huge NONO for mobile.

Some conclusions I've made so far.

Sprite count on screen is directly related to draw calls. Sometimes fewer bigger sprites is better.

Sprite count is directly related to CPU performance, especially when it comes to picking objects. The more objects you have to pick from the heavier it is.

In this case also, less is more.

I think that 'for each' is a real hog, when having to go trough a lot of objects that need a personal outcome.

So lets do something wild.

https://www.dropbox.com/s/eoxma2kzjj4r4 ... .capx?dl=0

Do you see how i avoid a 'for each' by using a container ?

Interesting. That's quite cool actually, I never thought of that. That might come handy in some cases.

For each is a pain, but sometimes picking just by a variable is enough.