Shouldn't be any problem. What you need to do is break down the images (enviroment)to foreground and background, probably in several different layers. depending on if the player can move in front or behind a certain object in the scene, and rebuild it in C2.

While the character is moving in Y axis (depth towards horizon) make sure to scale the character as he get's further away or closer to the camera, for the desired effect that he is moving in depth.

Then you compare the Y of your character with the Y of the object. If the character Y is lower that means he is further away, so should be behind any objects with a Higher Y, so you sort the Z order accordingly. Make sure to place all the default imagepoint at the base/feet (lowest point of each object). If i have time I can make a quick example for you.

Covering the whole screen/layout with something Is usually not very good. Have you tried the webGl effects? I also think i would be better if each shadow is seperate to each building etc. A bit tideous to place all the shadows, or maybe if you name all the sprites smart you can have events place all the shadows with code to each object that is supposed to cast shadows?

Looks nice! How many levels are you planning to have? Any bosses?

The point seems to be the filtering. Here's an image and capx of different events doing exactly the same thing.

1. First way is super heavy as it does not filter at all, goes through all and does it.

2. Second way is a bit cheaper as it filters by is on screen first. Very useful.

3. Even better is this weird way. On par with behaviours. First Checking opacity across the entire layout, picking the closest one setting it to 50, moving on to the next closest one setting it to 50, until it reached the distance limit of 150. Another event does the reverse thing to set it back to original opacity outside the distance limit. Super cheap and efficient.

4. Using the Line of Sight behaviour to do exactly the same thing, sligtly cheaper than no.3. Line of sight can even replace "is on screen" as an even cheaper substitute for filtering by screen size if you set the radius slightly bigger than the window width.

Conclusion, there are some good ways to do things and some bad ways. So far line of sight, and 'pick nearest/furthest' seems to be the most efficient ways to pick/filter.

capx:

https://dl.dropboxusercontent.com/u/20560446/Scirra/differentways.capx

I was having some performance issues and tried to figure out what caused it, but i was pretty sure it had to do something about the picking. So i created a new scene to test it out, and these were the results.

In my game i was using evaluate a lot, which seems to be very heavy on CPU. I was using it mostly because it looked neat to have everything in the same condition. But after doing this test I probably have to rethink a lot of my picking. Could anyone with deeper knowledge explain why some method is better than the other?

capx:

https://dl.dropboxusercontent.com/u/20560446/Scirra/pickperformance.capx

I turned off collisions for my weather effect "paricle" objects because they aren't needed... and CPU usage dropped from 15% to about 8% when the weather is coming in "heavy".

Having un-needed collision checks does seem to make a difference, especially when there's a lot of them happening.

~Sol

Yeah. Turning them off is always good when not needed, but constantly updating on/off is another thing. I have one project where i turn off collisions based on if they are on screen or not, and if you're moving around a lot in the layout, The turning on/off seems to be causing some jumpy scrolling.

Sprite - Is on Screen -> Collisions Enabled

Sprite - Is not on Screen - Collisions Disabled.

So if you have a lot of sprites constantly moving in and out of screen, switching from disabled/enabled seems to cause some hiccups. Constanlty Z ordering all sprites in layout seemed to have a similar effect, so I optimized my Z ordering to only sort objects that actually needed to be sorted. For my isometric game, I'm only sorting 2 instances at any given time, the one in front and the one in back, and only if:

Pick by evaluete: Family1.Y > Family2.Y & Family1.Zindex < Family2.Zindex

or

Pick by evaluete: Family1.Y < Family2.Y & Family1.Zindex > Family2.Zindex

-> Call function Order (param 0: Family1.UID) (param 1: Family2.UID

On function "Order".

Pick Family2 by evalute: function.Param(0) &function.Param(1)

Family2 is on Screen

-> Set Family2 instance var "SortValue" to. Family2.Y

-> Sort Z Order by Family2.SortValue

// This causes the the function to trigger only 1 time, since the function will sort only any objects that does not have the correct sorting, and all the previous events will be false, so no more sorting is needed.

This blogpost explains a bit why Z order has to be preserved in render cells. That's why I optimized my Z ordering, but it seem's turning collisions on and off, on the fly is heavier than just keeping them on, and could be causing the stuttering I'm experiencing.

https://www.scirra.com/blog/ashley/14/how-render-cells-work

After a lot of testing I've found out that one of the cheapest if not THE cheapest in terms of CPU load for picking/filtering objects is using the condition "Is on Screen", so I use it everywhere and filter by this first, if I can. I don't know why that's the case, but It seems to be so. Even if you write your own equivalent doing the same thing with events that condition (is on screen) seems to be a lot cheaper CPU wise.

Maybe it's because the "is On Screen" is working under the hood in a much better way.

This is the case especially if you have many objects.

So here's some useful Sprite/Family picking conditions that should be considered in the sprite/family conditions dialogue.

* Is within distance/radius to (Filtering if XY are within a certain distance/radius)

* Is Intersecting BBox (Filtering if other sprites/family intersecting the BBox) VERY useful.

* Is within angles of sprite angle (Filtering if XY is within ## degress of ## angle) like the line of sight behaviour.

* Is above/below 2 points. (Filtering if object is above/below or left/right 2 XY coordinates)

These are some of the conditions I use mostly, which if done with event feels like they are more heavy than necessary.

Maybe behaviours could be used to do the same thing? If anyone good with creating behaviours know's how to do this, I'd be happy to pay for it.

2 finger operations like pinch for zoom, and scroll with 2 fingers works in the layout view, so it's a bit touch friendly already.

> How big is the game? Took me ages to load the Beta. Or maybe just my connection is bad momentarily.

>

Sorry for the late reply. It's around 60mb of data. It was about 45mb before the newest update... adding too many egg sprites.

Thanks for playing! How do you feel about the game?

Nice job, very well done. The only part i was judging felt a bit long, especially after you played a few times. I wanted the results quicker. It could be sped up a bit.

ASHLEY. It could be a windows 10 bug, but a lot of other softwares fire the right click context menu on tap & hold which is the standard right click equivalent when using touch, not only stylus.

For example. Photoshop handles the tap&hold in the interface but not on the canvas (by design) so it must be something that has to be supported by the software i guess. My FTP software handles tap&hold, intel XDK is not very touch friendly but fires context menu on tap & hold. Maya handles tap&hold also. When it fires the circle touch indicator will turn to a sqare. I suggest buying or borrowing a touch enabled win 10 device to test it.

Ashley, Thanks I didn't get that at first, so you can close the bug.

I have a quite a lot of sprites that I turn on and off collisions for depending on if they are on screen or not. Since I did this optimization I seem to get a bit of stuttering when the game scrolls (on mobile). Without this optimization i get better frame rate and no stuttering but higher CPU usage.

Without optimization i have around 20-40 collision checks/tick

With optimization usually about around 2-5 collision checks/tick.

Does the turning on and off of collisions for sprites do anything behind the scenes that could be causing this stuttering? Collision cells that needs updating?