As I know you are aware, performance is currently hurting Lime, so I would like to put my vote in for some form of off-screen culling method so that I (and other developers) wouldn’t have to worry about implementing something in Lua. [import]uid: 5833 topic_id: 5910 reply_id: 305910[/import]
+1 [import]uid: 5712 topic_id: 5910 reply_id: 20314[/import]
I recently posted this to the “Feature Request” forum, and jmp909 contributed some ideas to it (but unfortunately our ideas pertained to culling of physics objects only, which would not help with Lime culling off-screen tiles).
http://developer.anscamobile.com/forum/2011/02/01/i-really-miss-world-limits-corona
Ideally I would like a method to cull all off-screen objects, physics-based or not, so +1 to this idea if it’s possible Ansca. 
Brent
[import]uid: 9747 topic_id: 5910 reply_id: 20387[/import]
I would like so that all visible objects hidden, animations stopped and bodies deactivated when they leave the screen and all are switched back on when they return. Naturally the original state of them would have to be saved out as you wouldn’t want a pre-hidden object to be automatically show just because it is now on screen.
I would then like to be able to manually set bodies/sprites/animations to be left activated when going off screen so that I can override the culling system in special cases. [import]uid: 5833 topic_id: 5910 reply_id: 20390[/import]
+1 [import]uid: 10484 topic_id: 5910 reply_id: 20410[/import]
+1 gazillion
but i do think the culling “radius” night need to be definable in some way. there’s got to be some kind of trade off between having something like a simple 2-screen X 2-screen display group pre-rendered to the GPU, rather than switching out parts of it, storing states temporarily until they need to be “un-culled” again.
but then i don’t know how OpenGL blitting etc works [import]uid: 6645 topic_id: 5910 reply_id: 20417[/import]
+1 [import]uid: 6981 topic_id: 5910 reply_id: 20424[/import]
+1 [import]uid: 9371 topic_id: 5910 reply_id: 20438[/import]
+1
The world limits from the other thread as well. [import]uid: 8800 topic_id: 5910 reply_id: 20458[/import]
+1 from myself as well.
Would actually help with the issue I posted about the other day:
http://developer.anscamobile.com/forum/2011/02/02/touch-event-can-freeze-corona [import]uid: 5883 topic_id: 5910 reply_id: 20462[/import]
As wonderful as it would be, I imagine “un-culling” would be technically difficult, but then, I’m not an “architect” type of programmer, just an aspiring game designer.
It’s one thing to remove off-screen objects, as we have all voted our support for. It’s another thing to re-display them if they venture back onto the screen or back within the “world limits”. Since they are all technically display objects, they are somehow being tracked internally by Corona. Moving them off screen but NOT deleting them from memory would probably bog down the system similar to what is happening now with Lime (as I understand it). For example, if Corona said “we have 120 tiles currently off the screen”, it would not display them, however it would still need to constantly track all 120 (or perhaps hundreds more) to determine when they should be “un-culled” and resumed to their original position. Seems like a hefty load on any mobile device, but as I said, I’m not an architect programmer.
It’s possible that simply culling them from the “visible” state would improve performance immensely. I don’t know how Corona handles its OpenGL system, i.e. whether it knows to stop processing pixels that reside off the screen.
[import]uid: 9747 topic_id: 5910 reply_id: 20476[/import]
@IgnisDesign
From the tests I have done making sprites that are outside of screen space (Screen Space Culling) set to isVisible = false has a marked performance increase when there are a good number of sprites (a couple of hundred, many or most of which are not on screen).
An example I had was attempting to run a map with tile sprites of 50x50 sprites of 32x32 pixels. Loading that on my 3GS gives a fps of about 2. Setting all tiles outside of the screen space to be invisible brings that right back up to 30fps.
You are correct that tracking if a sprite is on screen can be taxing but it is essentially a collision test (and something you improve the performance of with quadtree methods or chunking etc). You certainly don’t need to track and check every sprite off the screen to the same detail level.
Ansca will be able to create a much more robust culling method at the lower level that they have access to than anything we’re going to manage. [import]uid: 5883 topic_id: 5910 reply_id: 20480[/import]
+1 [import]uid: 11904 topic_id: 5910 reply_id: 20531[/import]
+1 Billlllllion Dollars [import]uid: 10243 topic_id: 5910 reply_id: 20554[/import]
+1 pretty please with knobs on. [import]uid: 8496 topic_id: 5910 reply_id: 20602[/import]
+1 [import]uid: 3399 topic_id: 5910 reply_id: 20614[/import]
+1 [import]uid: 8782 topic_id: 5910 reply_id: 20653[/import]
IgnisDesign: if the objects are, say, tilemap sprites then “unculling” them is simply a case of recreating the sprite and blitting it to the screen again, so it would be ok to remove it entirely during the culling process.
The problem arises when the tile is in a state of animation for instance, since you would need to recreate these properties on it too
Also, because physics is tied in with display objects directly, removing them becomes an issue if they are part of a physics world as you’d want the item to still exist in the physics would but not in the display.
Over to Ansca… [import]uid: 6645 topic_id: 5910 reply_id: 20688[/import]
Back to you, we don’t want this… 
We are aware of this and we are working with lime projects to increase p4mance
c [import]uid: 24 topic_id: 5910 reply_id: 22408[/import]
I hope you can find a more general solution as this is not just limited to 3rd party implementations.
Simply having a large number of sprites off screen is a major drain. [import]uid: 5883 topic_id: 5910 reply_id: 22412[/import]