Page 1 of 1

Actor out ov vision vs destroyed actor

PostPosted: Thu Feb 21, 2013 12:34 pm
by lverona
If an actor does not receive events when out of vision, does he eat up many resources when he goes out of vision permanently? Is such an actor same as destroyed or is it better to force destruction?

To be sure, I am so far not destroying such actors and the game performs well.

Re: Actor out ov vision vs destroyed actor

PostPosted: Thu Feb 21, 2013 7:38 pm
by lverona
Anyone can help out with this? Sky, can you advice?

Re: Actor out ov vision vs destroyed actor

PostPosted: Thu Feb 21, 2013 7:41 pm
by skydereign
It's kind of hard to test this one. But intuitively I'd say that destroying them is better, if you know they will never come back, and you have no use for them. I presume it works somewhat like activation regions do. But the reason it is hard to test is that the major part of any lag in gE is due to drawing actors. So if the actors are off screen, this is no longer a factor. Especially so if they don't receive events. In general though, the fewer actors you have, the better off you are.

Re: Actor out ov vision vs destroyed actor

PostPosted: Thu Feb 21, 2013 8:04 pm
by lverona
Well, I can say I have literally dozens and dozens of those left behind and gE seems to behave fine. I did not do it on purpose though, I do have a destroyer line sweeping unused actors up, but just today I figured that enemies which are killed and which get their Collision State disabled would not get destroyed. I can of course add to every enemy an Out Of Vision event or try indeed to use inheritance of sorts, but while it works I'll keep it.

Re: Actor out ov vision vs destroyed actor

PostPosted: Thu Feb 21, 2013 8:58 pm
by skydereign
lverona wrote:Well, I can say I have literally dozens and dozens of those left behind and gE seems to behave fine. I did not do it on purpose though, I do have a destroyer line sweeping unused actors up, but just today I figured that enemies which are killed and which get their Collision State disabled would not get destroyed. I can of course add to every enemy an Out Of Vision event or try indeed to use inheritance of sorts, but while it works I'll keep it.

Well as I said, any real lag you are ever going to experience in gE is due to drawing actors on screen. You can run into collision lag but most cases you won't, due to bounding box separation.

Re: Actor out ov vision vs destroyed actor

PostPosted: Fri Feb 22, 2013 6:40 am
by lverona
When I woke up this morning, I discovered my brain was working on an alternative solution.

I can create a "dead" object and put all dead animations there and when I shoot a base, destroy it and put a dead object with a proper animation in its place. The dead animation will have collision state enabled, but will have no events reacting to bullets or such and will have an Out of Vision->Destroy Actor event.

Do you think this is a good solution?

Re: Actor out ov vision vs destroyed actor

PostPosted: Fri Feb 22, 2013 6:44 am
by skydereign
If you have an out of vision event to destroy it, why would you want collision state enabled? I thought collisions were only for the clean up actor, which wouldn't be needed if you have an out of vision event destroying it. Of course enabling/disabling it doesn't have any impact if nothing has collisions with it anyway. But the idea sounds good.

Re: Actor out ov vision vs destroyed actor

PostPosted: Fri Feb 22, 2013 7:53 am
by lverona
Haha!
Sorry, you are correct. But while I was writing a sentence, I understood I do not need a collision, I just add an Out of Vision to this one Dead object and forgot to correct my sentence =)))

By the way, how long away from view does Out of Vision work? When is the object considered to be out of vision?

Re: Actor out ov vision vs destroyed actor

PostPosted: Fri Feb 22, 2013 8:00 am
by skydereign
It is determined by the safe margin setting in the game properties window (Config->Game Properties). The safe margin is the number of pixels extra the actor needs to be out of view (from their width/height bounding box).