begginer question about background creation

I am used to tile engines for creation of backgrounds and "rooms". Tile engines are efficients, memory and display wise, it only displays the part of the tilemap that is on screen, so you can build a 1000x1000 map if you want and there should be no slowdown.

I know construct doesn't have one (yet) and aims more for a free-form engine where the background is created with sprites (a la Aquaria)

My question s: how efficient is it?

How are the sprites that are not on screen managed? are they all 'ticked' even when not on screen?

How many sprites can I use for a background before the engine starts to slow down?

It'll vary on each person's computer based upon their processing speed, but a tile engine will still use sprites for the tiles. If a sprite is offscreen it is not drawn. I can have upwards of 100,000 offscreen or invisible sprites in a layout without slowdown on an athlon X2. Onscreen/visible, that number would be quite lower.

Normally a tile engine doesn't use sprites for ALL the tiles of the map.

It should use just enough sprites to cover the screen, and then map these sprites to the relevant tiles on the memory map.

you can code this yourself directly in construct, but it can be a bit tricky for beginners.

Also, there is no need to do this unless you notice slowdown in your game, because the runtime is hardware accelerated and very fast.

How are the sprites that are not on screen managed? are they all 'ticked' even when not on screen?

Yes, but you can add code which stops cpu-intensive events if the sprites aren't onscreen.

sprite is on screen

subevent -run checks

subevent -more tests

this way, sprites are only checked to be onscreen, and won't eat up cpu doing all kinds of other tests and checks when not needed.

Unless your game is a very small resolution (320x240), then optimizing graphics will be your main concern.

another useful fact might be that sprites which are offscreen are not rendered and don't impact performance in this regard; that means that you won't need to set them to invisible when not on screen or something similar to save resources - directx/the graphics hardware does that automatically.

as far as i remember, sprites stop drawing as soon as their center is further than 1 (or 2) times their width away from the screen's edge... i stumbled upon that when messing with distort maps :P

Okay, thanks for the info, Construct might be able to handle large levels it seems.

Construct does need to do a tiny bit of processing on each off-screen sprite every tick, but it's little more than a passing glance, computationally. You'd need thousands of sprites before the overhead became anywhere near the processing time of drawing those objects which are actually on the screen!

Well my maps in newest project can be 5000x5000 as I use tiled background and not so many sprites its very fast still.