Max Layout Size / Object Count?

Just a quick question.

Is there a maximum size that a layout should be set at? And is there a maximum object count? Recommended sizes and counts, rather than absolute limits.

I've been planning on running pretty big layouts, hand painted in Photoshop for a tiled background with hand-painted sprites placed on top for interactive elements such as buildings and trees. I've been working on a layout of 16000 by 6000 pixels so far, and am planning to have a lot of trees set on top as sprites, with events running every tick to check whether the player is behind them and to lower their opacity if he is, and with the intention of having them all animate to sway in the wind.

Presumably the performance will vary from system to system. But is there a recommended layout size and object count to cater to a broad range of computers, and is that above layout likely to be too taxing?

Ok... that didn't end up being such a quick question, but hopefully it isn't too hard to answer! Thanks for reading <3

Over 5000 objects would probably be pushing it for low end machines, and large layouts should be fine (there's no memory/cpu usage proportional to layout size so it essentially doesn't matter how big a layout is). The only issue is objects store their position in single-precision floating point numbers, which means they might start getting inaccurately calculated at really big X/Y co-ordinates - it should be OK within 100,000 pixels of the layout origin though. You could always experiment with a slow moving object at (100000,100000) and see if it still moves OK (use unbounded scrolling to save having to make a layout that big).

You'll probably get better performance with smaller levels with less objects: currently, construct has to check every object in the layout, no matter how far away it is from the screen, to see if it needs to be drawn or animated. This incurs a tiny performance penalty, but in theory having over 10,000 objects in a layout could slow down the game purely because those objects exist.

Oh wow, so maps around 20'000 pixels should be fine.

Thanks for clearing that up for me

How do non-solid offscreen objects affect performance?

I might have a Jillion of them :s

On my machine, I can manage 100,000 sprites before it dips below 60fps. That's with no code and them all invisible/offscreen, though.

How do non-solid offscreen objects affect performance?

I might have a Jillion of them :s

Do you mean invisible objects? Or transparent objects? Or really objects without the solid attribute?

Invisible objects don't affect the graphic performance, but might affect the processor load (e.g when using PVs from them).

Transparent and objects without the solid attribute that are offscreen don't affect the graphic card's performance, but they do add to the main processor load. There is no magic that decides when an object has to be drawn, animated, rotated, etc, because it's onscreen. Instead of magic there's simple calculation. Unless Construct will have some mapping that puts the objects in groups of importance (in relation to their distance from the current screen), this means calculating all objects' distances from the current screen.

Objects without the solid attribute, so they are not involved in collision calculations.

Since I want only to involve the onscreen objects and I'll have a rather complex zooming/rotating screen... I guess I could early-cull in every condition by making the first condition a distance test to the center of the screen.... would that work?

Something like this:

+distance from tree to screen center > threshold
+if player overlaps tree
-> bounce[/code:3kwm34dr]

would this avoid checking THE ENTIRE LAYOUT THAT'S CHOCK FULLA TREES and just check the trees that are visible or nearly visible? (provided a correct threshold)

Madster: that's correct, if you use a condition to filter down the objects before checking an overlap, then the overlap is only checked on those instances matching the previous condition. (That's the normal operation of conditions - filtering down instances condition by condition.)

The fact invisible offscreen sprites still affect performance is for two reasons:

1) If they're animated, the animation still needs to be ticked along so when they come back they're showing the correct frame. If they only have one animation with one frame, though, I think an optimisation kicks in that does no processing at all, though.

2) Construct must check every renderable object every tick to see if it needs to be drawn. Even invisible sprites are checked - it will just say, "oh, this one's invisible, next please". If it is visible, it does a very simple is-on-screen check (determine the bounding box then one to four integer comparisons) and if it's not on-screen it skips to the next one as well. These are trivial and take a tiny amount of time on modern processors, but with hundreds of thousands of objects these tiny tests become significant. 100,000 objects at 60 frames per second is 6,000,000 checks a second.

If you like calculations, since that's running on a single core at probably around 2.5GHz, each sprite takes about 400 cycles to check, which is about 160 nanoseconds. Yep, most games probably don't have to worry about that!

It's possible to improve the engine such that invisible or offscreen objects don't even need to be checked like that - it's something I'll consider for Construct 2.

1) If they're animated, the animation still needs to be ticked along so when they come back they're showing the correct frame. If they only have one animation with one frame, though, I think an optimisation kicks in that does no processing at all, though.

Cool, so that decides whether I have two animations or a single zero-speed animation with two frames for my trees makes no difference for me, but if two animations is faster, then I'll use that.

Does "is on screen" account for rotated zoomed layer plus rotated zoomed system crazyness? 'cause I'm using a lot of that >_<

I guess I'll test right now.

Edit: it doesn't :s

Does "is on screen" account for rotated zoomed layer plus rotated zoomed system crazyness? 'cause I'm using a lot of that >_<

It doesn't work with zooming, haven't tried rotating.

guess I'll stick with my distance-based filter instead of "is on-screen"

Makes me wonder though if it optimizes it at all, since it has to be tested on all the trees, and calculating square roots isn't exactly all that fast. And surely collision detection starts with bounding box testing, so that if bounding boxes do not overlap, no per-pixel calculation is done. And I'd think bounding box overlaps would be a lot faster to calculate for all trees compared to their distance to player.

But if you really want to do some sort of distance checking, I think something like this (using Is number between) would be more optimized:

Is tree.X between player.X-ScreenWidth/2*Zoomlevel and player.X+ScreenWidth/2*Zoomlevel

Is tree.Y between player.Y-ScreenHeight/2*Zoomlevel and player.Y+ScreenHeight/2*Zoomlevel

-> Check for overlap