# declaring variables in a render/game loop: good idea or bad?

I was just wondering how most of you like to declare your variables: for a variable you know will be used and changed frequently (i.e. every frame), do you declare those outside of the loop and simply change them? Or do you declare new variables every time around and count on the GC and function scope to clean up 60 little variables every second? Which is more efficient and reliable? Flash has a decent garbage collector, but I've had problems with leaks before.

Here's some example AS3 code with collision checking in Flashpunk:

public function update():void
{
var bullet:Bullet = collide("bullet", this.x, this.y) as Bullet;

if (bullet)
{
FP.world.recycle(this);
bullet.destroy();
}
}


vs.

var bullet:Bullet;

public function update():void
{
bullet = collide("bullet", this.x, this.y) as Bullet;

if (bullet)
{
FP.world.recycle(this);
bullet.destroy();
}
}

• Welcome to GD.SE! This question isn't really specific to game programming (it is a really general programming question), and has also probably been asked many times before on Stack Overflow (although I don't know that for sure). Honestly, this question would be better asked on Stack Overflow (or possibly Programmers) as it will get better answers. – Polar Aug 13 '13 at 19:57

There's no heap memory allocation taking place here and that's the only type of memory allocation you should worry about.

var bullet:Bullet = collide("bullet", this.x, this.y) as Bullet;


This line checks if the entity collided with another entity of type "bullet" and returns the first entity of that type. And since the method is Entity, there's a cast to Bullet (although I fail to see why this is even necessary). The important thing here is that var xy is not allocating memory with each iteration (except for memory on the stack, but that's a non issue), nor does it trigger garbage collection. It's basically the same as writing var bullet outside of the function scope.

if (bullet)
{
FP.world.recycle(this);
bullet.destroy();
}


The rest of the code recylces the current entity by feeding it back into an object-pool. The destroy method on the bullet is not part of the FlashPunk engine (AFAIK), but it might also feed it back to an object-pool or maybe also free references, so that the bullet can be garbage-collected. This is actually a point where your two code examples might behave differently. If you have the bullet variable as a class-member (eg. outside of the function scope), then you'll keep a reference to the bullet which will prevent garbage-collection of the bullet as long as the bullet variable still points to the bullet. FlashPunk even seems to enforce/encourage good practice by providing object-pools etc.

TL, DR: Unless you need the bullet variable outside of your update loop, you should always use the local scoped variables.

• The way AS3 works, it doesn't auto-cast and throws an error if you declare bullet as a Bullet object, so I have to cast it with "as". destroy calls FP.world.recycle and generates an explosive particle effect where the bullet was. It's something I added to Bullet myself. Since it uses recycle, it'll go back into a pool. The next frame, collide would return null, except that this enemy entity is then recycled and thus update is no longer called. Thanks for clearing up the whole stack/heap thing for me. Wasn't sure how Flash handled references to objects. – Eric Dand Aug 13 '13 at 22:07
• @EricDand Ah I see. Yeah, if destroy is a function of the Bullet class, then you obviously need the cast. There's also an article about heap/stack and garbage collection in flash. You might want to check it out if you're interested in further details. – bummzack Aug 14 '13 at 6:22
• This article's fantastic! I wonder how I've never found it before. Thanks for all your help: this should answer many more future questions about best memory practices with AS3. – Eric Dand Aug 14 '13 at 17:04

There isn't much difference between the two approaches IMO. I'm guessing the collide function creates and returns a new object in every tick anyway. It's okay to use any approach in most cases.