New Behavior: Is On Screen
-
Function: Returns true if the object is on screen (visible/rendered), if not, returns false.
Use 1; runner games: If off screen, spawn new terrain, destroy self.
Use 2; Generic Games: If off screen, reset health, graphic, events. Disable complex AI, Enable teleporting (sharp movement) If off screen too long, destroy object.Description: Checks is an object is currently visible to the player. Returns ‘true’ if it is visible, ‘false’ if it is not.
-
@thecheater887 Not a bad idea. Would work better than having big wall objects on each screen corner and detecting collisions with them.
-
@aidan-oxley This is usually known as culling, of one sort or another.
@Thecheater887 , in your first example, it's better to reposition and reuse (known as pooling) rather than destroying and creating. Destroying requires garbage collection, of a sort, which is always slow, and new creation requires memory allocation and initialisation, also not quick. Repositioning is lightning fast.
Unfortunately pooling is difficult to do in hyperPad because of the need to setup unique referencing through faux IDs. I've done it, but it took a lot of fiddling to get it working.
Your second scenario, the switching ability, is a very good idea. Some form of culling flag required, via a bounds check.
I agree. Both of these would be great, and should be added at a behaviour level, in hyperPad.
Pool, plus get object from pool and return to pool
Culling flag set on out of bounds, set on in bounds. and an observer for both.
-
I also agree. This functionality can dramatically influence the performance of newer games that includes huge amounts of objects, would help a lot! :)
