Much like imagepoints where you can add more, it would be great to have more collision polygons per Sprite. Current workaround is to create a dummy sprite which is not very handy. You can either have these dummy sprites within a container of an object or you can create a the dummy sprites with actions. Either way this is kind of a pain to work with.

It would be nice if these could be used through expressions using index based collision polygons

Sprite1.CollisionPolygonAt(0) Is overlapping Sprite2.CollisionPolygonAt(3) - or something in terms of that.

Another thing that would be nice is enabling collisions for BBox boundaries as well.

Sprite1.BBox is overlapping Sprite2.BBox

Strange - when I make a new project i don't get the same effect. Have to investigate further. In my project there is a group with events which keeps hovering around 1 to 1.5% CPU usage (mostly this group contains set position every tick on several sprites) even when all the events in the group is disabled - the group still uses around around 0.6% cpu... When i replicate in a blank project the same kind of events only take 0.4% CPU... and 0.1% CPU when disabled.

Another question. I would imagine that the structure of the events would play some role as well. For example... If you have an event, which is false, will any further sub-events be skipped by the system and not checked, or are they still run through and checked?

I would imagine that using sub-events well could limit a lot of checks that way. If the first event is false & placing many related events within that one, instead of creating a new event under, with the same conditions would save on some quite a lot of checks?

Throughout my project i have lots objects where their position is set every tick to the position to another object. Doing a little bit of testing turning off these particular event saves me a lot of CPU budget, but then again objects wont follow. It's not really the draw calls that make up for these CPU usage, but rather the setting of all the numbers every tick.

I've read all the optimization guides but want to go more in depth on how to optimize the events as I'm aiming to make a quite complex game for Mobile so every tiny bit of CPU usuage i can save on seems like a very good idea. I've identified the "on every tick" event as a major resource hog. So....

Will (Pin Behaviour) Pinning an object to another one instead of using On every tick > set position to > sprite.X sprite.Y or is there any other way that I've missed that might be better.

I know we're talking minimal tiny ammounts of CPU per object, but everything adds up quite fast.

The thing i would try is to change the keybidings probably. Moving with wasd feels more natural for me and then aiming up down with up & down arrow maybe? That's just my preference or what I'm used to, so maybe you can add an options menu with "reversed" keybindings? I would suggest trying some different setups with people to see which feels more natural. otherwise... nice game.

Best suggestion would probably be to make the draw gun a "toggle switch" instead of having to hold it... for less fingertwisting.

Reversed Control suggestions:

WASD movement (A&S) Can alternatevly be used as aiming as well as up down arrow.

Make draw gun a toggle switch using (F) for less fingertwisting. or use (LEFT SHIFT)

Fire - (Enter)

Reload (R)

Medpack (C or R Shift)

Roll (R Ctrl)

(Space) when you hear a ding and ! appears in the top right to inspect/use.

Nice game, but the controls take's a bit getting used to, once i got the hang of it it played quite well.

Charming game! Great job!

Finally!!!!!!

I this is all i needed. Now my z ordering only uses 0.6% CPU even with LOTS of objects on the screen.

Sharing if anyone else might need to optimize.

Trigger once while true will only trigger once while true..

Hence it only triggers once..

I would do the z-sorting on collision with player..

That will only trigger once if the player collides, but depending on how you've set things up, it could cause issues if you want the player to be able to walk through..

Yeah, i had some issues with that too. I tried soooooo many ways to optimize now im going nuts. Haha. Even dummy objects to use a second collision box. Any way, i want to limit the CPU usage in any way in can, and right now Z Ordering is my biggest resource hog, so i have to keep trying to find ways to optimize it.

Im gonna try using the oldValue idea there...

> Heres an example of what Im trying to do. The problem is that the for each loop only runs once. So how do i repeat it?

>

>

>

You have the trigger once condition there, right?

If you remove it, it might not only trigger once..

I'm also wondering why you have the else statements, by the way..

I would just do it like this

system pick all z-order

> z-order move to layer "infront"

system pick z-order by comparison z-order.y+z-order.elevation > Playerbase.y

> z-order move to layer "Behind"

Thanks. I did that before, but what im trying to do at this point is to optimize my code to use less CPU, hence the trigger once conditions. What i dont want is for values to be set, layers to changed and zSorting done every tick.... For Example: The Z sorting could be done only when an object switches layer to either infront or behind. If im not doing that the Zsorting only will use about 10-20% CPU with lots of objects on screen. Sorting smart, I managed to get it down to 0.8% CPU for sorting, by only sorting only things that needs to be sorted, Like overlapping objects, only when they need to be sorted.

Heres an example of what Im trying to do. The problem is that the for each loop only runs once. So how do i repeat it?

I have a Family of objects. Whenever a particular instance variable on any of those change i want to call a function. What is the best way to go about this? I also want the function to be called once, not every tick while the value is not same.

I tried hundreds of different things now but can't seem to grasp it. And this is how my latest try looks:

For each "Family1"

variable 1 = 0

Else

Trigger Once > call function

I can't seem to get it to work as intended.