Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (540)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  notification if animation has ended ...  (Read 1581 times)
0 Members and 1 Guest are viewing this topic.
Offline Serethos

Junior Devvie




Java games rock!


« Posted 2004-12-01 10:53:36 »

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 ...
 Roll Eyes


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)
Offline kevglass

« JGO Spiffy Duke »


Medals: 219
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2004-12-01 11:04:33 »

It depends entirely on a whole bunch of other things Smiley

For example, if you're Sprite->Animation interaction is thus:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
Sprite {
   tick(delta) {
       anim.tick(delta);
   }

   render() {
        Image image = anim.getCurrentFrame();
        image.render();
   }
}


Then its very easy. You just ask the animation if its finished once you've ticked.

However, your scenario might be completely different. This process is normally refered to as Design Wink

Kev

Offline Serethos

Junior Devvie




Java games rock!


« Reply #2 - Posted 2004-12-01 12:10:46 »

its very similar to your example except that the animator ticks automatically. the sprite-class only calls getCurrentFrame().
sure, i could do something like
1  
2  
if( animator.hasEnded() ) 
           rideTheChicken();


but such things are always a little dumb and not the really event driven ...

as a workaround i use the other method of adding the spriteclass like a listener to the animator object. if the animator's listener != null it notifys it.

the question whether to use the first or second method is a little like memory VS cpu.
first needs permanent method calls with value comparision, second needs extra references for little use.

perhaps i should mention that i only think that much about those little issues cause its for a handy game where common design patterns are generally thrown over board.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

« JGO Spiffy Duke »


Medals: 219
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2004-12-01 12:22:04 »

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... Smiley

Kev

Offline Serethos

Junior Devvie




Java games rock!


« Reply #4 - Posted 2004-12-01 12:43:26 »

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 ...  Grin  

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 ...
Offline Malohkan

Senior Devvie




while (true) System.out.println("WOO!!!!");


« Reply #5 - Posted 2004-12-01 12:51:54 »

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.

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
Offline kevglass

« JGO Spiffy Duke »


Medals: 219
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #6 - Posted 2004-12-01 12:55:01 »

Quote

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.

Kev

Offline shmoove

Junior Devvie




Doh!


« Reply #7 - Posted 2004-12-01 13:25:14 »

Unless you can think of a few more places where you'd like to listen for events from the the animation class, I'd go with the simpler check-the-boolean solution.

shmoove
Offline Malohkan

Senior Devvie




while (true) System.out.println("WOO!!!!");


« Reply #8 - Posted 2004-12-01 15:38:10 »

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.

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
Offline Serethos

Junior Devvie




Java games rock!


« Reply #9 - Posted 2004-12-01 17:31:07 »

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..
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Malohkan

Senior Devvie




while (true) System.out.println("WOO!!!!");


« Reply #10 - Posted 2004-12-01 17:43:28 »

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.
1  
2  
3  
4  
5  
6  
7  
for (int i = 0; i < size; i++) {
      animation[i].run();
      if (animation[i].isDone()) {
            remove(i);
            i--;
      }
}

And have your remove() method remove that slot and change the "size" variable.

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Mr.CodeIt (24 views)
2014-12-23 03:34:11

rwatson462 (53 views)
2014-12-15 09:26:44

Mr.CodeIt (45 views)
2014-12-14 19:50:38

BurntPizza (85 views)
2014-12-09 22:41:13

BurntPizza (110 views)
2014-12-08 04:46:31

JscottyBieshaar (79 views)
2014-12-05 12:39:02

SHC (89 views)
2014-12-03 16:27:13

CopyableCougar4 (96 views)
2014-11-29 21:32:03

toopeicgaming1999 (155 views)
2014-11-26 15:22:04

toopeicgaming1999 (152 views)
2014-11-26 15:20:36
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!