Objects on layouts vs. event creation

Discussion and feedback on Construct 2

Post » Tue Apr 23, 2013 2:25 am

Are there any performance differences between putting a bunch of objects on a layout vs. using events to create them at runtime? Just curious.
Project Lead of Zems Online Card Game

Producer at Impulse Limited
B
18
S
6
G
3
Posts: 677
Reputation: 5,194

Post » Tue Apr 23, 2013 2:32 am

My guess is the hit for having them on the layout is in the initial memory consumption and load. Creating them at run time gives you much more control of where and when they come into the layout which I would think may make avoiding some slowdowns a bit easier. Can't test it right now though as I am on a train...
B
49
S
11
G
10
Posts: 1,833
Reputation: 14,428

Post » Tue Apr 23, 2013 11:41 pm

This is my thinking as well, although the download size/memory usage hasn't really changed much after I moved everything to event-based creation. I figure download size doesn't change because you're still loading the same sprites that have to be downloaded anyway, but I thought memory usage might change. My project is still sitting at 24.7MB expected memory usage.
Project Lead of Zems Online Card Game

Producer at Impulse Limited
B
18
S
6
G
3
Posts: 677
Reputation: 5,194

Post » Tue Apr 23, 2013 11:48 pm

It matters when you have a huge map made of tiles. Creating them just offscreen as it scrolls means you control how many objects are created. Whereas, creating that huge map in the layout is a huge performance hit.
B
15
S
5
G
7
Posts: 877
Reputation: 5,650

Post » Wed Apr 24, 2013 12:13 am

@procrastinator

Can you give an example of how you would create them offscreen efficiently? I know you can invert 'is on-screen', but that alone is no better than just creating all the objects on the layout. How do you determine when the screen is 'close' enough to the object to have it created?
Project Lead of Zems Online Card Game

Producer at Impulse Limited
B
18
S
6
G
3
Posts: 677
Reputation: 5,194

Post » Wed Apr 24, 2013 1:32 am

I have a basic tilemap loader going using xml files exported from PyxelEdit. I'll try and work up a scrolling example tomorrow (remind me though ;p).

For a simple example that I can explain now, I'll use Gradius. You'd store the whole level in an array. Draw all the tiles that are "onscreen" in the array. When scrolling through the level, every X seconds you'd use an offset in the array to draw the new column offscreen, and increase the array position by 1. When the tiles.X are less than -TileWidth (offscreen to the left), then you'd destroy those. So a level that would potentially have 1000s of tiles, you're only processing / moving a couple of hundred or less. This is why C2 isn't efficient with tiles placed in the layout as it processes / moves all of them.

Hope I explained that ok. I'm pretty tired mentally right now ;)procrastinator2013-04-24 01:33:55
B
15
S
5
G
7
Posts: 877
Reputation: 5,650

Post » Wed Apr 24, 2013 2:39 am

@procrastinator

I'm not quite used to working with arrays, so I'm interested in how you populate an array to store the layout objects/information.
Project Lead of Zems Online Card Game

Producer at Impulse Limited
B
18
S
6
G
3
Posts: 677
Reputation: 5,194

Post » Wed Apr 24, 2013 3:21 am

An array can be 1D, 2D or 3D, and can only store a single number or text per entry. Read the manual on arrays first, it explains it pretty well.JoyfulDreamer2013-04-24 03:30:51
Jack of all trades, and master of some.
B
29
S
9
G
7
Posts: 174
Reputation: 7,601

Post » Wed Apr 24, 2013 4:01 am

I know what arrays are, I'm just not used to using them to store objects.

For example, my space shooter game has asteroids floating around. If I understand correctly, these can be 'destroyed' once they get outside of a certain range but their movement can be tracked in the array so that if the camera ever gets close, they can be created and given the associated speed/direction.

Maybe that's a bit complicated, but that's what I was thinking of. Sure, one can leave them unrendered since they are off the screen, but if they are moving, they are still consuming memory. Updating in an array takes up a smaller amount of memory, and so for performance reasons I can see this being done.

procrastinator's example seems to apply to tiled/grid based games, whereas a game like my shooter isn't bound to a grid.Excal2013-04-24 04:03:31
Project Lead of Zems Online Card Game

Producer at Impulse Limited
B
18
S
6
G
3
Posts: 677
Reputation: 5,194

Post » Wed Apr 24, 2013 4:20 am

You're right, I did mean tile based games. I just assumed that, because you brought up placing objects in the layout. I'm not sure you'd see much of a performance gain by doing just what C2 does - tracking every object. It would probably be slower to access an array 1000+ times in one go rather than just letting C2 do its job.

That's not to say that splitting the whole level into segments and only dealing with the objects in that segment (array) wouldn't have a positive effect.

The main reason it works for tile based games is because you're only accessing a small portion of the array at a time. That's why splitting it into segments could work, but that depends on the game really.
B
15
S
5
G
7
Posts: 877
Reputation: 5,650

Next

Return to Construct 2 General

Who is online

Users browsing this forum: Silverforce, Zebbi and 14 guests