Offscreen vector graphics.

Hi Guys,

Let’s say I draw 10,000 lines in a scene about 20,000px by 20,000px. I then move the camera around this scene. Only about 100 lines will be on screen at any-one time (forgive my maths if I’m way out there, just using this as an example).

Do I need to manually remove and create the lines when they come onto the screen, or does corona do that automatically?

I wasn’t sure if this was specific to 2.0 or not, sorry if it’s not!

Thanks a lot.

What you are looking for is culling - IE you create all 10000 lines, and it only *draws* the ones on screen.

Does Corona do this? On a rough level, yes. Whether it is enough for your needs is another matter entirely (10000 is a looot of lines). You could just try it and see how fast it goes?

You could let Corona do this, but you incur a cost b/c we have to figure out what’s not onscreen. 

Corona’s culling works best on a fine-grained level where the objects are in the vicinity of where your “camera” is pointing. If you have lots of objects that are not even close to where the camera is looking, you’re burning up performance by letting Corona do culling. Instead, your code has higher level information that can be leveraged to do coarse-culling of the scene. 

This lack of coarse-grained culling is what has made performance lag on some 3rd party libraries (e.g. Lime). Conversely, it is what has made others perform well (e.g. Million Tile Engine).

I’m not sure I got this, and it might be important in our current development.

We have a side scroller shooter with a parallax scene. The scene width is 5*480 and we create and load it all in advance, put it in a parallax and just scroll through the map. We also pre-load and position all the mobs putting them in “sleep” mode until you come close enough.

Are you saying it’s much better for us to dynamically load the objects as you scroll along? I’m probably misunderstanding the term culling…

Yes, the coarse culling is like loading just screens 1+2 until they move to screen 2. Then your high level code unloads ( object:remove / removeSelf ) screen 1 and loads screen 3…

He’s saying your high level code knows what can’t possibly be displayed, and by design, can massively reduce the amount of things that need to be removed (culled) come every single frame render. Having those other screens not even in the list of things could mean thousands of objects not being processed (60 times a second).

Ok, so in our case each level is a continuous scroll to the right when enemies awaking as you get near them, we can easily break these scene into “sectors” and load only the sectors that are visible or “nearly visible”.

The drawside of this is that the scroll might not be smooth while we dynamically load new objects. We’ll certainly test it out.

Just to update this;

There weren’t quite 10,000 objects, but almost! 

What I’ve done is build up an index of what needs to be shown and what needs to be deleted at anytime and it seems to work perfectly. It wasn’t that difficult to implement either.

I did a similar thing for an older game I did (14px - platformer), but it wasn’t very well optimised! I wish I could go back in time and recode that game!!

Thanks.

What you are looking for is culling - IE you create all 10000 lines, and it only *draws* the ones on screen.

Does Corona do this? On a rough level, yes. Whether it is enough for your needs is another matter entirely (10000 is a looot of lines). You could just try it and see how fast it goes?

You could let Corona do this, but you incur a cost b/c we have to figure out what’s not onscreen. 

Corona’s culling works best on a fine-grained level where the objects are in the vicinity of where your “camera” is pointing. If you have lots of objects that are not even close to where the camera is looking, you’re burning up performance by letting Corona do culling. Instead, your code has higher level information that can be leveraged to do coarse-culling of the scene. 

This lack of coarse-grained culling is what has made performance lag on some 3rd party libraries (e.g. Lime). Conversely, it is what has made others perform well (e.g. Million Tile Engine).

I’m not sure I got this, and it might be important in our current development.

We have a side scroller shooter with a parallax scene. The scene width is 5*480 and we create and load it all in advance, put it in a parallax and just scroll through the map. We also pre-load and position all the mobs putting them in “sleep” mode until you come close enough.

Are you saying it’s much better for us to dynamically load the objects as you scroll along? I’m probably misunderstanding the term culling…

Yes, the coarse culling is like loading just screens 1+2 until they move to screen 2. Then your high level code unloads ( object:remove / removeSelf ) screen 1 and loads screen 3…

He’s saying your high level code knows what can’t possibly be displayed, and by design, can massively reduce the amount of things that need to be removed (culled) come every single frame render. Having those other screens not even in the list of things could mean thousands of objects not being processed (60 times a second).

Ok, so in our case each level is a continuous scroll to the right when enemies awaking as you get near them, we can easily break these scene into “sectors” and load only the sectors that are visible or “nearly visible”.

The drawside of this is that the scroll might not be smooth while we dynamically load new objects. We’ll certainly test it out.

Just to update this;

There weren’t quite 10,000 objects, but almost! 

What I’ve done is build up an index of what needs to be shown and what needs to be deleted at anytime and it seems to work perfectly. It wasn’t that difficult to implement either.

I did a similar thing for an older game I did (14px - platformer), but it wasn’t very well optimised! I wish I could go back in time and recode that game!!

Thanks.