Looking at the list of events, all I can think of right now is giving each star a physics body and then making physics body rectangles at each of the 4 edges of the screen and detecting a collision between a star and one of the edge rectangles. I feel like this would work but seems very backwards.
You’ll have to write your own testing code. There is no listener for this.
Consider this. I assume you want this for a speedup? However, if the SDK were already testing this, it would be a costly feature only occasionally used.
Sorry, but you’ll want to write your own and simply skip testing every other frame or so to get better performance. Also, optimized your test calculations for better results. The code I’ve given you can be further optimized.
PS -
If you want to use physics,
-
Create a single static body that covers the whole region you want to consider on-screen. (set isvisible to false)
-
Make that body a sensor (obj.isSensor = true)
-
Add bodies and collision listeners to the ‘to be tested’ objects.
-
Check for “began” and “ended” phases, where “began” indicates entered on screen space, and “ended” indicates left on-screen space.
I’m trying out this physics solution, I’ll let you know how it turns out.
Okay I have it working with the screen sensor and the stars as individual objects, but to save of resources, I am grouping the stars and then changing the x and y position of the group. I’m noticing this does not change the x and y position of the group. Is there a way to apply group position locations to its children efficiently?
“I feel like this would work but seems very backwards.”
You’ll get over it. ;)
The “correct” way to tackle these sorts of problems is by splitting up the world so you can deal with (approximately) only the part you need: space partitions
These are, unfortunately, a lot of work to write and debug. However, Box2D (any physics library, for that matter) would have found itself in more or less the same straits you are now, just as a matter of course, so the author already went ahead and implemented one, e.g. see here and here. So it’s a perfectly good solution.
On your last comment (posted while I was writing this), you could group several stars together and just move the entire group when it’s all offscreen. In this case you could just have an invisible boundary object, say a rect, around them and test collisions only against that.
Thank you for your response, but I have a new idea that I am going to try to implement. Up to this point I have by updating the position of the stars by a certain number of pixels each frame. Now I am going to try to set them each on a never ending moveBy() call. Early implementation of this is that the stars are killing themselves off and disappearing shortly after they hit the bottom of the screen and are being reset to the top…
Does changing the x or y position of an object while a moveBy() call is being performed on it not a good idea? Or should this be okay?
While it’s being performed is a bad idea, yes… the next update will just undo it; if you notice it all it will just look glitchy. However, the onComplete handler is provided for this sort of thing.
If you do go this route, note that you’ll want to use different time parameters on your initial transition than on your resets after that, just because the first batch will already be in progress.
Thank you for providing this information, I will factor this in while forming my solution.
This ended up working out by resetting the MoveBy() call every time a star leaves the screen sensor. Thanks everyone!