2 things I guess:

-the evaluation of the expression might be simply taking more time than the actions (don't think conditions are instantaneous, in some cases they take more time that actions).

-the CPU measure of C2 is not accurate enough for a small case (and even for larger ones), it is really a ballpark figure and nothing more, if the difference for the small case is minor, then don't really care about it that much, as the inaccuracy and debug alteration might play a bigger role.

Thanks. Difference is not that huge. But there are some tradeoffs.

The Picking way, Uses less CPU that the For each way, but as the sprite count increases, and seems fairly constant even with large numbers of sprites in the layout.

The for each way gets more heavy as the number of sprites increases, but is using less CPU when the sprite count is low.

i think i have to do some more experimentation on the picking events.

Right now I'm using picking sprites in several steps with conditions.

Condition1, picks only the sprites on screen.

Condition2, picks only the sprites on the specific layer.

Condition3. picks by evaluating only the sprites(in a family) that are above the player.Y & left of player X & distance is less than 150px from player.

Most of the time this limits the picking to 1 or 2 sprites picked.

If all the conditions are met a function is called & Moves the picked sprites to another layer, so they will not be picked again.

I was messing around trying to optimise some parts of my game tried out picking objects (pick by evaluate) instead of using for each, and seemed it used more CPU than a for each loop on ALL objects in the family.

Even when the picking event returned false and not running any actions it was using more CPU than the For each event doing the same thing every tick.

How is that possible?

In my mind the picking would limit the amount of actions to be done as an optimisation but turns out it's using more CPU. If the picking event didn't find a match the event would be false right? nothing to be done... so how come it uses more CPU than running a for each loop with no picking...

Very strange.

If you make the cannon ball a "bullet" using the bullet behaviour you can set the gravity.

https://www.scirra.com/manual/90/bullet

I guess that's what you mean?'

I got help with a similar problem in this thread before. Maybe this can help you out.

https://www.scirra.com/forum/viewtopic.php?f=147&t=148511

Ashley I took one tilemap after export from C2, and ran it through the tool and saved around 70% size. I'm wondering though, as a sprite with animations exports as a single/multiple spritesheet, is there any way to have other sprites bundle together in the same manner without using the tilemap object (since the sprites vary a lot in size and are not constant 64x64 sprites?) One workaround would be to load all the different sprites on to a single sprite object and per instance set the animation frame or animation/name. Or is there any easier way I might have missed?

I'm using around 20 different sprites at the moment, some tiny, some larger, and they all export as their own individual sprite sheet, so it would be great if all sprites without animations that are exported were bundled up in the same manner as sprites with animations.

Some constructive feedback.

* You should add more pony colors to the ingame shop.

* Bad FPS when the light is on, so i keep it off.

* I noticed there is a bug in the left corner, but i cant tell what type of bug. Maybe a spider or a grasshopper.

And i found one bug.

* When my mom calls i cant play. I have to focus on the phone call. Any fix for that coming?

Nice to see the multiplayer working flawlessly. I've been playing with my imaginary friend for hours!

I also wish there was an easy way to create weighted paths or splines that objects could follow. Maybe there is a plugin for that, not sure. The pathfinding can find the a route between points. Did you try it out?

Getting errors when i try the game using the CocoonJS Launcher App.

Exported with cordova exporter.

If you're using "set position" you can try set position to:

X: lerp(Self.X, Mouse.X, 0.03)

Y: lerp(Self.X, Mouse.X, 0.03)

Reducing or increasing the last value vill change the speed. That will make the speed slower/smooth.

Otherwize I would use Move object at angle, for more control.

Move object at angle.

Angle: angle(object.x, object.y, mouse.x, mouse.y)

speed: 3 ?

Nice improvements! Looking good. Nice dark feeling to it!

goldenskygiang I don' think the loader is going to ruin your business. If you make a great game that becomes popular you would probably earn enough to buy the business version. I understand that a personal loader will look a bit more professional and fit the graphic style of your game, but if people like your game they are not gonna stop like the game because of a loader. Most professional games mention what engine/technology was used to make it, so don't worry about it too much.

Not sure if i get it right, but you could on a function call make an array for each imagepoint which contains the distance between that imagepoint and the closest ones, then sort this array based on the values. When sorted you can get the lowest value and connect to that one... shouldnt be too heavy on performance if you can narrow down to first checking which "swarm is closest"..... so, in theory. 1 check which swarm is closest. 2 populate an array with the distances of the imagepoints from swarm A and B. 3 sort the array to get the closest distance. 4. connect.... something like that.