“I remove objects and recreate them with the new tile image at the other side of the screen”
That’s what I meant - I didn’t need code or deep explanations. I just wanted an idea of how you do it.
So let me get this straight:
Caleb [import]uid: 147322 topic_id: 35666 reply_id: 142353[/import]
Yes, that’s the gist of it. [import]uid: 99903 topic_id: 35666 reply_id: 142362[/import]
Thanks!
C [import]uid: 147322 topic_id: 35666 reply_id: 142375[/import]
@Brent (or someone else) - just trying to understand what Corona does re culling exactly - can you clarify? Specifically in terms of minimising texture memory? I’ve been thinking of culling as helping with texture memory, but perhaps when people use the term culling it is more re rendering. So does this mean that whilst Corona does culling for games that are multiple screens worth, that this in itself doesn’t help minimise texture memory usage, and that you really need to do this yourself with some sort of intelligent creation/removal of display objects (like the guys were talking about)? (making the assumption here one is already using sprites)
Hi Greg,
As you presume, culling is about rendering, not about texture memory. Corona will not render off-screen content each cycle, but you won’t save texture memory by just placing items off screen or making them invisible. OpenGL loads the textures in, and there they remain until you un-load them. So yes, the answer is, you need to control this yourself IF you imagine your texture memory will be pushed near its limit.
I don’t know what kind of game you’re designing, but one of the best ways to handle this is to create objects that can be re-used. When they leave the screen, you can recycle them to enter the screen from the other side (in the case of a 2D scroller, for example). This helps performance in other aspects too (not re-creating objects all the time), so you should consider that strongly.
Brent
Hi Brent - thanks - can I check:
a) for repeating background pattern then, you should probably make the size of the ‘tile’ relatively big then, say 128x128 (as opposed to 32x32), as if you’re going to put display objects across the whole level (including off screen) in place from the beginning it wouldn’t make much difference re texture memory, however the smaller tiles would mean lots of display objects hence I assume this would be bad for performance? Am I correct? Any guess on a good size for the repeating background image?
b) Could I still just allocation the physics body for the ground outline once fro the entire level? (i.e. output from PhysicsHelper after sucking an image of the overall level). So I could just choose the top level ground sprite/tile so to speak, but then apply the whole “addBody” with path there. This seems to work I think, however the question is is there any memory/performance overhead? In fact it would be faster no, then putting physics bodies on each of the tiles/sprites?
Hi Greg,
It’s hard to suggest and ideal size for repeating tiles… 128x128 seems OK, but if you have large spans of a relatively solid background, you might do better with 512x512 on just those bigger areas. This will, of course, take up more texture memory, but also take the place of 16 of the smaller tiles.
Yes, you can build a “mock” physics ground object that is invisible and just spans over the ground tiles. If your ground is just flat and ongoing, this is definitely better for performance.
Brent
@Brent (or someone else) - just trying to understand what Corona does re culling exactly - can you clarify? Specifically in terms of minimising texture memory? I’ve been thinking of culling as helping with texture memory, but perhaps when people use the term culling it is more re rendering. So does this mean that whilst Corona does culling for games that are multiple screens worth, that this in itself doesn’t help minimise texture memory usage, and that you really need to do this yourself with some sort of intelligent creation/removal of display objects (like the guys were talking about)? (making the assumption here one is already using sprites)
Hi Greg,
As you presume, culling is about rendering, not about texture memory. Corona will not render off-screen content each cycle, but you won’t save texture memory by just placing items off screen or making them invisible. OpenGL loads the textures in, and there they remain until you un-load them. So yes, the answer is, you need to control this yourself IF you imagine your texture memory will be pushed near its limit.
I don’t know what kind of game you’re designing, but one of the best ways to handle this is to create objects that can be re-used. When they leave the screen, you can recycle them to enter the screen from the other side (in the case of a 2D scroller, for example). This helps performance in other aspects too (not re-creating objects all the time), so you should consider that strongly.
Brent
Hi Brent - thanks - can I check:
a) for repeating background pattern then, you should probably make the size of the ‘tile’ relatively big then, say 128x128 (as opposed to 32x32), as if you’re going to put display objects across the whole level (including off screen) in place from the beginning it wouldn’t make much difference re texture memory, however the smaller tiles would mean lots of display objects hence I assume this would be bad for performance? Am I correct? Any guess on a good size for the repeating background image?
b) Could I still just allocation the physics body for the ground outline once fro the entire level? (i.e. output from PhysicsHelper after sucking an image of the overall level). So I could just choose the top level ground sprite/tile so to speak, but then apply the whole “addBody” with path there. This seems to work I think, however the question is is there any memory/performance overhead? In fact it would be faster no, then putting physics bodies on each of the tiles/sprites?
Hi Greg,
It’s hard to suggest and ideal size for repeating tiles… 128x128 seems OK, but if you have large spans of a relatively solid background, you might do better with 512x512 on just those bigger areas. This will, of course, take up more texture memory, but also take the place of 16 of the smaller tiles.
Yes, you can build a “mock” physics ground object that is invisible and just spans over the ground tiles. If your ground is just flat and ongoing, this is definitely better for performance.
Brent