i often stumble over a problem concerning my animation sequences:normally each sprite has 1..n animation objects for controling all bitmap-based animation sequences. therefore the relation of both classes is single wayed

sprite ---has--> animation

but sometimes i need to know the exact moment when a sequence has just ended. e.g. the sprite exploded so after that it can be removed.

i only see two solutions:- a bidirectional relationship so that every animation can consult its sprite reference(which can be somewhat tricky cause all other animations which do *not* require to notify the sprite do not know that they shoul not do so ... this would require more additional workarounds)

- i could permanently ask: are you finished ...are you finished ...are you finished ...are you finished ...are you finished ...are you finished ...

btw: in general if you need back references for very special purposes, dou you rely on using normal references correct or do you write interfaces just for this purpose (or use observer or whatever)

I think you have to ask yourself why you wouldn't just use the straight forward method. Checking a boolean each frame really isn't going to be a CPU choker. You'll have much more important optimisations than that to worry about...

What flexibility/reusability is adding the AnimationListener interface really giving you in your use case? If its none or a weak answer that you find yourself wondering about then its probably not really worth it...

And of course if it is later, we work in a wonderful refactorable language called Java...

perhaps it my very personal feeling, but i dislike solutions, where events occur but are tested permanently.

sure, i know, with this logic i should feel uncomfortable with the whole collision detection ...

only aspect i have for my defense is that handy programming forces you enough to replace good design with clumsy code where everyone references everyone and tests if it should test the test ...then theres a time, where you try to avoid this crap ...

you should only care if it's a difficult calculation to check to see if the boolean is true. As in, you have a game which requires a difficult check and loop through all of the objects in your scene to decide if a game is won, but if you just let the objects themselves say, "hey, I'm there, end the game now" you could finish and not have to check every object every tick. Since you're just checking a single boolean, or probably comparing two numbers, that's a silly thing to optimize.

only aspect i have for my defense is that handy programming forces you enough to replace good design with clumsy code where everyone references everyone and tests if it should test the test ... then theres a time, where you try to avoid this crap ...

I agree entirely. But what I'm asking if this small nuance of your code is really worth worrying about just yet.

also consider in this case... either you check every time to see if the animation has finished, or the animation itself checks every time to see if it's finished. I can't forsee a way you'll get out of that single boolean check. Firing an event once you know it's done means you've already discovered it's done... meaning you just did the check you would have done otherwise. The only difference is not only are you firing an unnecessary event, but you're also having to catch it and handle it.

the event firering isnt extra work:in my animation class i have to test whether the end of the sequence is reache, e.g. to loop it from beginning, play it backwards, whatever. sure, this is an aspect which grows out of my animation class design..

exactly, you have to test to see if it's reached. When it is, you remove the animation, it's as simple as that. You have to do that test either way. Might as well handle it right when you find it's true rather than have the intermediate step of firing and handling the event.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org