Layout size/Offscreen object performance hits

Hello!

Dug up an old Construct Classic thread and wondered if this still stood:

scirra.com/forum/max-layout-size-Object-count_topic41024.html

basicly, running a 40k x 40k layout size with a 64x64 tiled background (size set on layout load) seems to incur some performance hit on mobile, also the performance does drop with 500+ objects spawned in the layout, 475-ish of which are off screen at any 1 time.

So yeah, it's not a massive performance hit, but it's the difference between a 30fps game and a 15fps one.

cheers

In theory the layout size and object size should not affect the performance more than having everything on one screen. There is not extra work for the engine to do. The object count is definitely significant though, especially if you are testing collisions.

Ashley

I found this interesting since we are talking about 500 object count on mobile performance. I found that even invisible objects(on screen set to invis or off screen), with collision off(set on the sprite property). I found that my iPodTouch 4g was limited to 500 objects to maintain 30fps. I was limited to about 120 objects visible and 60 objects that moved(collision on/off).

So there is certainly a performance hit just for having sprites exist even if they are not rendered, have no collision check in either the sprite setting or events.

jayderyu - were they animated? Sprites with a single animation with a single frame should not need any overhead, but if they have any other frames at all the engine will have some overhead for them ticking them to ensure the animation frame stays up to date.

Ashley

They only had 1 frame, but they might have still had the frame rate set to 5. I will check that out and do some more tinkering.

Again, I don't feel this is a killer problem. I checked what IOS devices are still running on IOS 6, and it's only %33 apx. And devices running IOS 7 seem to run very well. And my Acer A500 runs on an early version of the Tegra2 which wasn't very well GPU acceleted. I get to run GTA3 and games, but dosn't run as smooth as the later Tegra2 chips. Let alont that most of the industry is Tegra3+ or equivelent. Most of the problems with Android is OS version number.

Though it was still odd at the time that sprites that had no visual impact were still eating up processing. I'll check things out some more and share the test capx. maybe I'm just doing something terrible and overlooking a detail.

ok. So here is my follow up. There were a few mistakes on my part that I overlooked :D. I made 3 errors in my prior performance statement

1. Gameplay on my iPodTouch and Acer A500 feel about the same. However tests show otherwise.

2. My setting sprite sprite should have been embeded with the create object not out side of the creat object. So my mistake was every tick I was setting states for EVERY SPRITE. Which of course will kill performance just for overhead

3. My last mistake was the blindspot on behaviours. Behaviours cost performance. Even when a behaviour does nothing it's still toll on the system and not a small one either. In the case of Pin when not pinned to anything; just having pin on all the sprites will cut peformance by a lot.

ok my test was every tick a new sprite is made if the FPS is greater than 30.

My sprite had a simple small graphic, but also had bullet and destroy on outside of layout.

*** Outside of view, Invisible, no behaviours what so ever

This is just a max object test I suppose. not much use.

Acer A500, 70k+

iTouch 5g, 16k

iTouhch 4g, 8000

*** Outside of view, visible, no behaviours what so ever

iTouch 5g, 4539 sprites

iTouhch 46, 1754

Acer A500, 20k+

*** Inside of view, invisible, no plugins

Acer A500 20k+

iTouch 5g 14k

iTouch 4g 8k

*** Inside view, visible, no plugins

AcerA500 2000

iTouch 5g, 1100

iTouch 4g, 400

*** Inside view, visible, Bullet Disabled

AcerA500 1900

iTouch 5g, 800

iTouch 4g, 300

*** Inside view, visible, Bullet Enabled speed 0.5(just for the process)

AcerA500 1700

iTouch 5g, 300

iTouch 4g, 100

*** Inside view, Invisible, Bullet Enabled speed 0.5(just for the process)

AcerA500 6000

iTouch 5g, 1000

iTouch 4g, 300

*** Outside view, visible, Bullet Enabled speed 0.5(just for the process)

AcerA500 3000

iTouch 5g, 350

iTouch 4g, 100

*** Outside view, Invisible, Bullet Enabled speed 0.5(just for the process)

AcerA500 6000

iTouch 5g, 1000

iTouch 4g, 300

*** Outside view, Invisible, pin behaviour

AcerA500 7000

iTouch 5g, 2000

iTouch 4g, 500

*** Outside view, visible, pin behaviour

AcerA500 7000

iTouch 5g, 1600

iTouch 4g, 500

*** In view, visible, pin behaviour

AcerA500 2000

iTouch 5g, 700

iTouch 4g, 200

*** In view, visible, pin behaviour, Bullet enabled(speed 0.5)

AcerA500 1500

iTouch 5g, 250

iTouch 4g, 90

*** In view, visible, Bullet enabled(speed 0.5), destroy on outside

This is a practical use for games like Space Blaster or Bullet Hell games

AcerA500 1500

iTouch 5g, 250

iTouch 4g, 80

Sooooo what do I take away from this. When designing mobile games. Minimize the use of behaviours. Much to my surprise they do hit performance and what may seem not so much can actually be really heavy. Sprites with no behaviours provide ample good performance even on old hardware.

Keeping in mind that those above values are numbers that are causing FPS to drop to 30fps

You might want to include that somewhere. The inclusion of behaviours will impact performance; so be frugal :D.

Here is my CAPX. I added and removed behaviours as noted above. The last state was used for testing bullet hell situation.

drive.google.com/file/d/0B0V2EvCXNzYUaDE2YW1QbHpfRjQ/edit