animated tiles and screen culling?

Lime
#1

Hi Graham,

I think it would be useful for the Lime engine to expose some sort of event for when tiles enter or leave the screen, so that we can handle things like starting/resuming/stopping a tile’s animation

Obviously it would be even better if Lime could handle this internally (another module maybe?). For one thing I’m not sure you’d actually want an event for each tile, since most likely it’s actually a row or column of tiles that is likely to leave the screen at any one time, so multiple events is overkill. Presumably therefore a list (table) of tiles that left or entered the screen would be preferable that could then be processed. I guess this needs some kind of optimized spatial hashing/bounds checking etc?

thanks for any feedback.
j
[import]uid: 6645 topic_id: 5033 reply_id: 305033[/import]

#2

Again, another very good suggestion :slight_smile:

I think for this it is best to wait till Ansca return with some news about their findings with Lime. It may turn out that something they can add to Corona is automatic handling of animations and physics bodies etc so that neither I or users of Lime/Corona ever have to think about it unless for any reason they wish to override the feature. Consider your request duly noted.

There is also currently the IsOnScreen() function however naturally an automatic thing would be nicer. [import]uid: 5833 topic_id: 5033 reply_id: 16509[/import]

#3

Thanks for the links to the tests, I will forward them on to Carlos now. Hopefully he can come up with a nice solution. [import]uid: 5833 topic_id: 5033 reply_id: 16662[/import]

#4

graham,

i have a couple of self-contained performance tests set up that might be worth sending Ansca’s way to see what they think of the rendering issues there

http://developer.anscamobile.com/forum/2010/11/13/performance-tip-setting-isvisiblefalse-slow-reading-display-object-xy-slow

http://developer.anscamobile.com/forum/2010/12/11/another-scrolling-performance-test

maybe having a lot of objects to check internally (even if they are not visibly rendered) may slow down the engine. ie currently presumably all sprites are referenced in memory at least even if they are not in the visible screen area. as opposed to dynamically reading the relevant chunk of the map data when needed and creating the sprites then.

eg as mentioned 15x10 * 50 screens wide = 7500 sprites, even if they’re off screen it still has to maintain an internal representation of the display group containing them, it’s size, their position etc. doesn’t seem like that’s going to be a very optimal way to do it.

but if using the “extra screen row & column, sprite swapping” method, that’s going to mess up integrated physics, which we dont have separate control over in relation to the display. (ie display objects and physics objects are currently interlinked)

I don’t know how GS does it internally, but I found games like Papa Wheelie actually perform quite well

j.

[import]uid: 6645 topic_id: 5033 reply_id: 16658[/import]

#5

[just updated that post above] [import]uid: 6645 topic_id: 5033 reply_id: 16663[/import]

#6

i’d be happy if we could get

* “unlimited” map size without physics (sprite swap method)
* limited map size with physics

i think that would be an appropriate trade off. although in the latter case presumably it’s going to be up to the user to optimize the amount of moving game objects etc vs map size.

but looking at eg GS again…


“without a lot of actors i know you can run around a game as big as 320x20000 and it works fine. As long as your actors dont pop on until they are close everything will be cool”

I just don’t know if there actually is a generic solution. If you look at something like Sonic (and Strille’s version) i’m sure all physics is not a continual integrated engine… it’s basically per tile-collision code, so you only need to worry about what’s on screen… presumably the world outside the screen doesn’t essentially exist as far as the engine is concerned

One thing to consider, though, when it comes to a continuous physics world as we have with Corona, is what do do with offscreen items. If you look at how it currently works if you drop an item off screen and print out it’s position it’ll continually fall “forever”. ie the physics engine still tracks it. How many objects can you have before this starts causing slow down? In particular though i’m thinking about a situation when i fire a ball at high speed so that it leaves the bounds of the screen, and it bounces off a wall further along my map (but not on screen)… really the ball would potentially bounce back, and therefore it’ll come back onto the screen again.

Some engines though would just delete the ball outside of a certain area, ie it would get deleted before it reached the wall further along the map

Again, i’ve discussed maintenance of off-screen physics here:
http://developer.anscamobile.com/forum/2010/11/22/scrolling-large-non-tiled-world-objects

I know i’m repeating posts a bit here… but just trying to point Ansca in the right direction for the good of their users :wink:

j

[import]uid: 6645 topic_id: 5033 reply_id: 16667[/import]

#7

I think it’d be nice to be able to have all off-screen tiles set to hidden automatically and all physics bodies set to sleep. Then when they come back on they are automatically shown/woken up. And then the developer would be able to override these on a per item/group/whatever basis so that you bullet example could still work (if you needed it to be able to bounce back that is.) [import]uid: 5833 topic_id: 5033 reply_id: 16676[/import]

#8

might be worth thinking about how “body.isBodyActive” could be used to optimize performance. (“Inactive bodies are not destroyed, but they are removed from the simulation and cease to interact with other bodies”)

i was thinking sensors (or distance functions) could be used to check whether a body needs to be made active again (put back into the simulation), but doing these checks in itself could be intensive operations if not also optimized well.

as an extreme case, what i mean is you wouldn’t want your game engine to be checking whether there are *any* moving objects approaching *any* collidable objects so that those collidable objects can be set to active and awake ready for collision, since these checks would probably slow the system down more than the performance benefits gained from setting the body to inactive in the first place.

I’d say therefore that even just overriding certain elements within the system, to set them not to auto-sleep, is not the most optimal approach. (The ball in my example for instance essentially could bounce off *any* off-screen solid object anyway). All i know is spatial hashing is probably the best approach to performing these check routines faster, but how this would be implemented depends on what the Corona engine does itself.

j [import]uid: 6645 topic_id: 5033 reply_id: 16705[/import]

#9

Yea it’s things like spatial hashing and other techniques that I assume would be better suited to being added to the engine itself rather than Lime, firstly because they would no doubt do a better job of it and have low level access to stuff but also it would benefit the whole of the community regardless of whether they are using Lime or not. [import]uid: 5833 topic_id: 5033 reply_id: 16719[/import]

#10

in that case we would presumably just need control over the grid size i presume (and possibly any subdivisions)

some good reading on Cocos2D methods if you do this search
http://www.google.co.uk/search?q=+spatial+hashing+box2d+tilemap

for instance here Patrick who made Crazy Taxi discusses splitting the map up into smaller chunks (display groups) as well as removing objects from the world entirely when they get a certain distance away from the player

http://www.cocos2d-iphone.org/forum/topic/4474

in the situation discussed this would potentially mean the ball doesn’t bounce back from the distant wall. would the player care? probably not, as it’s probably not an essential gameplay element

reading through some of the links, would suggest splitting up the map into separate display groups. Can objects in Corona be inserted into separate display groups visually but still interact correctly physically?

as regards Box2D, it already has a Dynamic Tree to optimize region queries so I’m assuming this is already in use internally for optimizing display operations?

http://www.box2d.org/manual.html (Section 4.11)

j

[import]uid: 6645 topic_id: 5033 reply_id: 16733[/import]

#11

in this post http://www.box2d.org/forum/viewtopic.php?f=3&t=292 the author of box2d, Erin Catto, suggests adding physics objects to the world dynamically based on distance from the player…

The best way to do that is by saving/loading the physics entities as needed. This is also true for rendering.

For example, if you have a side scroller then don’t keep stuff more than 2 screens away.

[import]uid: 6645 topic_id: 5033 reply_id: 20965[/import]

#12

That does seem like the best thing to do for both visual and physics and though technically it could be implemented in Lime we would have the same problems with Lua not being great for this sort of stuff as well as only benefiting Lime users. It would be great if this could get baked directly into Corona.

In the thread about blending and tinting - http://developer.anscamobile.com/forum/2011/02/03/blend-modes-tinting - Carlos says “+4 — we are starting to architect new graphic gpu enhancements - some of them are to address you Mr. Particle Candy Man ;-)”

Hopefully that will include culling additions. [import]uid: 5833 topic_id: 5033 reply_id: 21014[/import]

#13

ah great. well I think there’s been enough fuss about it display optimization to warrant some re-work! :slight_smile: And I’m presuming Eric has some experience with this anyway.

brownie points to kwigbo for his platformer tutorial too.

now if you can just get all those GS Platformer Kit features in that i sent you :wink:
[import]uid: 6645 topic_id: 5033 reply_id: 21073[/import]

#14

Yup, I’d say our plight has certainly been heard and I can’t wait to see the results.

Yea I was really happy that he decided to create one and hope he has the time to make more.

I will do, one by one, but they will all be in. Either directly in Lime, via tutorials with properties or possibly berries. [import]uid: 5833 topic_id: 5033 reply_id: 21181[/import]

#15

Are the berries back? Had forgotten about them. Got to get back into it. [import]uid: 11904 topic_id: 5033 reply_id: 21334[/import]

#16

At present they are not however I *hope* to get them back in for 2.8 [import]uid: 5833 topic_id: 5033 reply_id: 21386[/import]

#17

Berries are good for you! Very healthy. [import]uid: 11904 topic_id: 5033 reply_id: 21580[/import]