469,325 Members | 1,637 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,325 developers. It's quick & easy.

Deleting Animations

I'm making a game. I need to maintain a bunch of objects, in this
case animations (explosions and stuff). I've decided to use an STL
vector. From my understanding, I need to declare it as
vector<Animation*so that I can insert new animations with something
like myAnimations.push_back(new Animation(...)); So that's all fine
and dandy, but what I can't decide on is how to delete this animation
after it's done playing (the explosion should be deleted and removed
from the vector when it's done cycling through all it's frames). I've
been told it's a bad idea to get an object to delete itself, because
then the caller won't know whether or not it still exists, and it's
just a bad design decision. So, would it be best to have some sort of
boolean in my animation object that says something like
"animationComplete", and when set to true the iterator would then
remove it? If so, what would my iterator look like?

for( vector<Animation*>::iterator current = myAnimations.begin();
current != myAnimations.end(); current++ )
{
(*current)->step(); // tells the animation to change frames
and do whatever it needs to do
if( (*current)->animationComplete )
{
current = projectile.erase(current);
delete (*current); // <-- is this right?
continue;
}
(*current)->draw(); // draw it
}

Code looks kind of ugly... is that really the best way of doing it?

Apr 27 '07 #1
14 1407
On 27 Apr, 05:53, Mark <mnbaya...@gmail.comwrote:
I'm making a game. I need to maintain a bunch of objects, in this
case animations (explosions and stuff). I've decided to use an STL
vector. From my understanding, I need to declare it as
vector<Animation*so that I can insert new animations with something
like myAnimations.push_back(new Animation(...)); So that's all fine
and dandy, but what I can't decide on is how to delete this animation
after it's done playing (the explosion should be deleted and removed
from the vector when it's done cycling through all it's frames). I've
been told it's a bad idea to get an object to delete itself, because
then the caller won't know whether or not it still exists, and it's
just a bad design decision. So, would it be best to have some sort of
boolean in my animation object that says something like
"animationComplete", and when set to true the iterator would then
remove it? If so, what would my iterator look like?

for( vector<Animation*>::iterator current = myAnimations.begin();
current != myAnimations.end(); current++ )
{
(*current)->step(); // tells the animation to change frames
and do whatever it needs to do
if( (*current)->animationComplete )
{
current = projectile.erase(current);
delete (*current); // <-- is this right?
continue;
}
(*current)->draw(); // draw it
}

Code looks kind of ugly... is that really the best way of doing it?
Is there any special reason why you don't just declare it as
vector<Animationand add new elements like this:
'myAnimations.push_back(Animation(...))', notice the lack of new?

Then all you have to do is to use erase() on the vector to delete
them, I think it's possible to add a predicate to erase so that it
only erases those where animationComplete is true.

--
Erik Wikström

Apr 27 '07 #2
mos

"Mark" <mn*******@gmail.com>
??????:11**********************@r3g2000prh.googleg roups.com...
I'm making a game. I need to maintain a bunch of objects, in this
case animations (explosions and stuff). I've decided to use an STL
vector. From my understanding, I need to declare it as
vector<Animation*so that I can insert new animations with something
like myAnimations.push_back(new Animation(...)); So that's all fine
and dandy, but what I can't decide on is how to delete this animation
after it's done playing (the explosion should be deleted and removed
from the vector when it's done cycling through all it's frames). I've
been told it's a bad idea to get an object to delete itself, because
then the caller won't know whether or not it still exists, and it's
just a bad design decision. So, would it be best to have some sort of
boolean in my animation object that says something like
"animationComplete", and when set to true the iterator would then
remove it? If so, what would my iterator look like?

for( vector<Animation*>::iterator current = myAnimations.begin();
current != myAnimations.end(); current++ )
{
(*current)->step(); // tells the animation to change frames
and do whatever it needs to do
if( (*current)->animationComplete )
{
current = projectile.erase(current);
delete (*current); // <-- is this right?
continue;
}
(*current)->draw(); // draw it
}

Code looks kind of ugly... is that really the best way of doing it?
I suppose it should be :

delete (*current); // first
current = projectile.erase(current); // second

and I almost use list as
for (it = list.begin(); it != list.end(); )
{
if ((*it).die())
{
delete *it;
it = list.erase(it)
}
else
++it;
}
Apr 27 '07 #3
mos
Hi
sorry for posting unfinished mail.
I mean you'd better choose list to do it than vector.

mos.
Apr 27 '07 #4
On 26 Apr 2007 23:22:17 -0700, =?iso-8859-1?q?Erik_Wikstr=F6m?= wrote:
>Is there any special reason why you don't just declare it as
vector<Animationand add new elements like this:
'myAnimations.push_back(Animation(...))', notice the lack of new?
I guess the reason simply is that he deosn't want to duplicate the
Animation objects. The reason why the original code looks so 'ugly' is
that STL was designed only for values, not for (pointers to) objects.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
Apr 27 '07 #5
"Mark" <mn*******@gmail.comwrote in message
news:11**********************@r3g2000prh.googlegro ups.com...
I'm making a game. I need to maintain a bunch of objects, in this
case animations (explosions and stuff). I've decided to use an STL
vector. From my understanding, I need to declare it as
vector<Animation*so that I can insert new animations with something
like myAnimations.push_back(new Animation(...)); So that's all fine
and dandy, but what I can't decide on is how to delete this animation
after it's done playing (the explosion should be deleted and removed
from the vector when it's done cycling through all it's frames). I've
been told it's a bad idea to get an object to delete itself, because
then the caller won't know whether or not it still exists, and it's
just a bad design decision. So, would it be best to have some sort of
boolean in my animation object that says something like
"animationComplete", and when set to true the iterator would then
remove it? If so, what would my iterator look like?

for( vector<Animation*>::iterator current = myAnimations.begin();
current != myAnimations.end(); current++ )
{
(*current)->step(); // tells the animation to change frames
and do whatever it needs to do
if( (*current)->animationComplete )
{
current = projectile.erase(current);
delete (*current); // <-- is this right?
continue;
}
(*current)->draw(); // draw it
}

Code looks kind of ugly... is that really the best way of doing it?
The way I'm doing it:

// Update ALL the -On-The-Fly- or Fired 'Beams' to NEW positions.
for ( BeamEffectsType::iterator it = Client.BeamEffects.begin(); it !=
Client.BeamEffects.end(); )
{
if ( !(*it).second->Update() )
{
delete (*it).second;
it = Client.BeamEffects.erase(it);
}
else
++it;
}

Although I'm using a map instead of a vector, the same logic should apply.

The only real difference between mine and yours is I have the function call
itself return a boolean. So you could have your step() return bool whether
to delete it or not. Also, your code is not removing the element from the
vector, which it needs to.
Apr 27 '07 #6
On 27 Apr, 11:23, rpbg...@yahoo.com (Roland Pibinger) wrote:
On 26 Apr 2007 23:22:17 -0700, =?iso-8859-1?q?Erik_Wikstr=F6m?= wrote:
Is there any special reason why you don't just declare it as
vector<Animationand add new elements like this:
'myAnimations.push_back(Animation(...))', notice the lack of new?

I guess the reason simply is that he deosn't want to duplicate the
Animation objects. The reason why the original code looks so 'ugly' is
that STL was designed only for values, not for (pointers to) objects.
I asked since in his original post he said that he wanted to use it
like this:

myAnimations.push_back(new Animation(...));

notice that he creates the object in the push_back, in which case my
solution would be just as good (or better).

--
Erik Wikström

Apr 27 '07 #7
On 27 Apr 2007 02:36:38 -0700, =?iso-8859-1?q?Erik_Wikstr=F6m?= wrote:
>I asked since in his original post he said that he wanted to use it
like this:

myAnimations.push_back(new Animation(...));

notice that he creates the object in the push_back, in which case my
solution would be just as good (or better).
Not quite. Your solution copies the new Animation object into the
vector and may copy all other objects in the vector due to relocation.
The pointer solution never copies Animation objects, just pointers.
Moreover, since Animation seems to be an object in the OO sense it may
be semantically problematic to duplicate these objects, i.e. the copy
constructor probably should private.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
Apr 27 '07 #8
On Apr 26, 11:53 pm, Mark <mnbaya...@gmail.comwrote:
I'm making a game. I need to maintain a bunch of objects, in this
case animations (explosions and stuff). I've decided to use an STL
vector. From my understanding, I need to declare it as
vector<Animation*so that I can insert new animations with something
like myAnimations.push_back(new Animation(...)); So that's all fine
and dandy, but what I can't decide on is how to delete this animation
after it's done playing (the explosion should be deleted and removed
from the vector when it's done cycling through all it's frames).
Why? Do you only use the explosion once in the entire game? You're
going to need a Cray to run your game if you allocate/load/delete
animations every time you play them.
Apr 27 '07 #9
On Apr 26, 11:22 pm, Erik Wikström <eri...@student.chalmers.sewrote:
On 27 Apr, 05:53, Mark <mnbaya...@gmail.comwrote:
I'm making a game. I need to maintain a bunch of objects, in this
case animations (explosions and stuff). I've decided to use an STL
vector. From my understanding, I need to declare it as
vector<Animation*so that I can insert new animations with something
like myAnimations.push_back(new Animation(...)); So that's all fine
and dandy, but what I can't decide on is how to delete this animation
after it's done playing (the explosion should be deleted and removed
from the vector when it's done cycling through all it's frames). I've
been told it's a bad idea to get an object to delete itself, because
then the caller won't know whether or not it still exists, and it's
just a bad design decision. So, would it be best to have some sort of
boolean in my animation object that says something like
"animationComplete", and when set to true the iterator would then
remove it? If so, what would my iterator look like?
for( vector<Animation*>::iterator current = myAnimations.begin();
current != myAnimations.end(); current++ )
{
(*current)->step(); // tells the animation to change frames
and do whatever it needs to do
if( (*current)->animationComplete )
{
current = projectile.erase(current);
delete (*current); // <-- is this right?
continue;
}
(*current)->draw(); // draw it
}
Code looks kind of ugly... is that really the best way of doing it?

Is there any special reason why you don't just declare it as
vector<Animationand add new elements like this:
'myAnimations.push_back(Animation(...))', notice the lack of new?

Then all you have to do is to use erase() on the vector to delete
them, I think it's possible to add a predicate to erase so that it
only erases those where animationComplete is true.

--
Erik Wikström
heh. I was just thinking about that, and I asked my friend if it was
possible, but he said it was necessary to use "new". Shows how much
he knows :)
This will help, thank you!

Apr 27 '07 #10
On Apr 27, 12:40 am, "mos" <mmosqu...@163.comwrote:
"Mark" <mnbaya...@gmail.com>
??????:1177645984.187561.111...@r3g2000prh.googleg roups.com...
I'm making a game. I need to maintain a bunch of objects, in this
case animations (explosions and stuff). I've decided to use an STL
vector. From my understanding, I need to declare it as
vector<Animation*so that I can insert new animations with something
like myAnimations.push_back(new Animation(...)); So that's all fine
and dandy, but what I can't decide on is how to delete this animation
after it's done playing (the explosion should be deleted and removed
from the vector when it's done cycling through all it's frames). I've
been told it's a bad idea to get an object to delete itself, because
then the caller won't know whether or not it still exists, and it's
just a bad design decision. So, would it be best to have some sort of
boolean in my animation object that says something like
"animationComplete", and when set to true the iterator would then
remove it? If so, what would my iterator look like?
for( vector<Animation*>::iterator current = myAnimations.begin();
current != myAnimations.end(); current++ )
{
(*current)->step(); // tells the animation to change frames
and do whatever it needs to do
if( (*current)->animationComplete )
{
current = projectile.erase(current);
delete (*current); // <-- is this right?
continue;
}
(*current)->draw(); // draw it
}
Code looks kind of ugly... is that really the best way of doing it?

I suppose it should be :

delete (*current); // first
current = projectile.erase(current); // second

and I almost use list as
for (it = list.begin(); it != list.end(); )
{
if ((*it).die())
{
delete *it;
it = list.erase(it)
}
else
++it;
}
I guess it looks nicer without the continue; statement. Thanks!

Apr 27 '07 #11
On Apr 27, 12:43 am, "mos" <mmosqu...@163.comwrote:
Hi
sorry for posting unfinished mail.
I mean you'd better choose list to do it than vector.

mos.
I was debating whether I should use a list or a vector... I was
thinking of ways I could get the animation to delete itself in which
case it would require random access, and I ought to use a vector...but
since I'm only iterating through it now, you're quite right. Thanks.

Apr 27 '07 #12
On Apr 27, 2:23 am, rpbg...@yahoo.com (Roland Pibinger) wrote:
On 26 Apr 2007 23:22:17 -0700, =?iso-8859-1?q?Erik_Wikstr=F6m?= wrote:
Is there any special reason why you don't just declare it as
vector<Animationand add new elements like this:
'myAnimations.push_back(Animation(...))', notice the lack of new?

I guess the reason simply is that he deosn't want to duplicate the
Animation objects. The reason why the original code looks so 'ugly' is
that STL was designed only for values, not for (pointers to) objects.

--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
Uhh..no, I was just being dumb. The animations need to be duplicated
I think because they have different values. Inside the animation
object is a pointer to an image, so there is only one copy of the
image regardless (hopefully), but the x,y values and stuff need to be
independent for each animation.

Apr 27 '07 #13
On Apr 27, 11:23 am, dave_mikes...@fastmail.fm wrote:
On Apr 26, 11:53 pm, Mark <mnbaya...@gmail.comwrote:
I'm making a game. I need to maintain a bunch of objects, in this
case animations (explosions and stuff). I've decided to use an STL
vector. From my understanding, I need to declare it as
vector<Animation*so that I can insert new animations with something
like myAnimations.push_back(new Animation(...)); So that's all fine
and dandy, but what I can't decide on is how to delete this animation
after it's done playing (the explosion should be deleted and removed
from the vector when it's done cycling through all it's frames).

Why? Do you only use the explosion once in the entire game? You're
going to need a Cray to run your game if you allocate/load/delete
animations every time you play them.
Well, like I said, it's not loading the actual image file each time.
But it is creating a new animation object each time something
explodes, however, it's only assigning it a pre-loaded image and an
x,y value. (That's okay, isn't it?)

Apr 27 '07 #14
rp*****@yahoo.com (Roland Pibinger) writes:
On 27 Apr 2007 02:36:38 -0700, =?iso-8859-1?q?Erik_Wikstr=F6m?= wrote:
>>I asked since in his original post he said that he wanted to use it
like this:

myAnimations.push_back(new Animation(...));

notice that he creates the object in the push_back, in which case my
solution would be just as good (or better).

Not quite. Your solution copies the new Animation object into the
vector and may copy all other objects in the vector due to relocation.
The pointer solution never copies Animation objects, just pointers.
Moreover, since Animation seems to be an object in the OO sense it may
be semantically problematic to duplicate these objects, i.e. the copy
constructor probably should private.
How about boost::shared_ptr? A quick test shows that
std::list<shared_ptr<myclass works as expected.

If not familiar: boost is a pool of c++ libraries (http://www.boost.org) that hope to make it
into the standard. I think shared pointer is way up on the candidate
list. It is wrapped around your pointer like so:

boost::shared_ptr<myclassp(new myclass(...));
std::list< boost::shared_ptr<myclass list;
list.push_back(p);

from there on that pointer is reference counted, so every "copy" will
point to the same object, and when there are no more copies (including
the first instance) the object is deleted autmagically. So

list.pop_back()

will actually delete the object, provided there is no other shared_ptr
holding a reference to it anymore.
cheers

daniel
Apr 27 '07 #15

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Michel Gaudry | last post: by
1 post views Thread by Garry Gaves | last post: by
1 post views Thread by dzemo | last post: by
1 post views Thread by DrXavier | last post: by
2 posts views Thread by Mike Stolkes | last post: by
reply views Thread by Gurmeet2796 | last post: by
reply views Thread by harlem98 | last post: by
reply views Thread by listenups61195 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.