Latest code updates - AnimationTimer and other ideas

[Daniel Zwolenski]

Hey Guys,

Look through Richard's code while on the plane. I didn't get a chance to pull in Jose's change before boarding but it's top of my list when I get somewhere stable (it sounds pretty good though and I am looking forward to seeing it in action).

Code base looks good - we've taken a step back functionality wise, but I'm good with that. Build it up slowly with a solid foundation we all agree on. 

So some comments on design/next steps: 

First thing that sticks out for me is the use of AnimationTimer vs Transitions. I feel like there's some inconsistency here (i.e. we have two ways of animating, which means two ways of pausing, two 

ways of thinking, etc, etc). My code in this area was pretty similar to Richard's and it feels to me as if the inconsistency is really at the JFX animation layer and the API is a tad off here - how 

do you guys feel about it?

Ignoring any possible API level changes I feel like we should at least come up with a consistent strategy. I think we can't get by without the "pulse" style functionality of the AnimationTimer. We 

need the "pulse" so that things can "think" (e.g. Tower needs to look for Enemies, bullet needs to check if it hit anything) and Transition doesn't really allow for this cleanly as far as I can see. 

On the other hand the Animation/Transition stuff is great in how simple it is to do complex stuff (like Path routing). We've used this to good effect in routing the path for Enemies but I'm wondering 

how long we will get away with this. If we try to slow or speed up an enemy, or if the enemey needs to react to it's surrounds (e.g. a Tower killing enememy that blows up when it is in range of a 

tower), then I suspect we will find ourselves limited by the Animation/Transition side of it?

So I'm wondering if there is any way we could use an Animation/Transition but instead of calling play() we manually call something like nextFrame() to an AnimationTimer - i.e. I kind of want the 

transition logic of the Transition but want to decouple it from the animation thread. Is this possible? Or do either of you have thoughts on better/alternate ways to do this?

Whether we can avoid the Transition or not, I'd also wonder if we could simplify the logic around AnimationTimer and instead of the current design, we have just one central AnimationTimer inside the 

Game object. We then have a GamePulseListener class that things can implement, and add themselves to the Game.addPulseListener(). Then we can centralise stuff like pausing (by just stopping the 

central animator) and also hide how the animation works (in case we change from an AnimationTimer to something else later). 

What are your guys thoughts on this?

I'd probably be looking to work next on this code base on Tuesday my time (probably Monday evening your time), so would be good to have something to target for that coding session. 

Some other things I think could be looked at: 

The Level doesn't need to be abstract in my book. If we had exactly as is, but not abstract, we could then create Levels without extending them (e.g. via FXML). For short ease term we can still just 

create the as you are by extending them, but it's not required. Unless there are objections, I would like to make it non-abstract.

The Towers currently get their shooting/targeting logic from within LevelPanel when the Tower is created (in the placeTower method). I'd be more inclined to move this logic into the Tower itself - so 

a Tower internally has a pulse method that decides how it shoots and what it shoots at. For example some towers might not even shoot, and might just increase the shooting tower of nearby Towers, etc. 

Some Towers might fire lots of missiles, etc, etc. To me it makes sense to put this in the Tower class. I'm guessing Richard, you just didn't get round to moving it, but if you had a bigger plan here 

let us know. If there's no objections by Tuesday I will likely look at moving this logic too.   

There are lots of other areas to add to but I'd be keen to focus on those first. I think the simple Wave approach that Richard has in there is probably not what we want longer term but I'd be keen to keep it as is for now (i.e. simple!) and focus on the other areas of the game first. The Wave stuff can be improved later in my book and this will be easier/cleaner to do when we have fully locked down other things (like path routing, tower placement, etc). 

I notice neither of you have joined the mailing list yet - I've cc'd the list on this email so it will get logged. It would be easiest if you both joined however and then we could all send only to that list instead of private emails. If there are objections to google groups idea, let me know. 

Cheers!

Dan

[Daniel Zwolenski]

I'll try and send more details on AnimationTimer vs Transition later but in brief have a look at the way Enemies update/animate (Transition with Path) vs the way Towers do (AnimationTimer with pulse method). Two quite different approaches, each with pros/cons. I'd be interested to see if Richard likes it as it is or has ideas on how it could be better. 

Regarding work on VectorEnemy, sounds like a very good place to look at. Keen to see what you come up with. 

On 16/12/2012, at 2:35 PM, Jose Martinez <jmarti...@yahoo.com> wrote:

Dan,

You lost me with the talk about AnimationTimers vs Transitions.  Is there somewhere in here where we are using Transition where it might be worthwhile to use something else?  I see these as being very different and am not catching onto to the overlap.  Never seen a situation where I could make a choice between whether going with a Transition or an AnimationTimer, but maybe that is just me not being creative enough.

I think the Transition that I have noticed so far was the PathTransition.  I do not see how this interferes with the Animator class object in LevelPanel.

I like the centralized AnimationTimer idea!  This is the main game loop.

I also agree about the Tower stuff.  I think having an abstract "pulse" method in Tower that will get called by the central AnimationTime is what I prefer at this juncture.  I think we should work on this next because it frees us up to do pretty cool tower implementations.

Going to work on a vector Enemy now.

thanks

jose

---

From: Daniel Zwolenski <zon...@gmail.com>
To: Richard Bair <Richar...@oracle.com>; jose martinez <jmarti...@yahoo.com>; fx-g...@googlegroups.com
Sent: Saturday, December 15, 2012 8:15 PM
Subject: Latest code updates - AnimationTimer and other ideas

[Daniel Zwolenski]

I've just had a bit of a look through the new AnimatedImageNode, nice work. There's some suggestions I'd make (e.g. don't start the animation until the Enemy is added to the level; pre-calculate and cache the Rectangles for the image clip of each frame; etc) but overall good job. 

One thing it does do is highlight the problem I'm feeling in this earlier email chain regarding Transitions. In this case we have two Transitions/Animations making up the overall movement of the Enemy - we have the external Transition (added in LevelPanel) which does the movement and the rotation, and we have an internal Animator which does the frame flipping. We get away with this because we have such a simple setup, but really which frame to show, the movement, the rotation, and all other rendering elements (explosions, taking a shot, taking a hit), etc, are all inter-related and should be all treated as one bit of logic. 

For example say our Sprite was isometric (i.e. viewed at a slight top-down angle instead of direct top down). In this case we would need to change the frame based on the rotation, not just rotate the image (e.g. if we used a Sprite like this: http://www.deviantart.com/morelikethis/254921757#/d3fjhn7). The knowledge about rotation is in one Animator, the knowledge about flipping frames is another. When we add in stuff like taking a hit, slowing/speeding up, adding an extra effect (like poisoned, etc) then all the rendering for these will be interlaced with which frame to show. Our current design would imply we create a separate animation for each of these. 

Additionally we now have two things to pause, stop, start, etc. and we need to make sure we destroy both Animations when the Enemny is culled (currently I think the internal animation will keep running). All of this would be simpler/cleaner with one animation. 

I'm starting to feel like we just won't be able to make much use of Animations/Transitions once things get even moderately interesting (i.e. within a few more coding sessions) and we will have to make everything "pulse" based. This is a shame because without Transitions we will have to do the Path routing ourselves. It would be great if we could use the path routing and rotating logic of the Transition, but avoid the actual Transition itself. I'm not sure if this is possible in FX(?) but if not I feel like we need to use the pulse() approach everywhere and write our own path rotating logic based within that context. 

As an aside, even if we stick with two Transitions, I feel the Transition logic for the Enemy should be inside the Enemy and not the LevelPanel as it is now (similar to the Tower logic being moved). The LevelPanel should pass the path through to the Enemy, and the Enemy should do it's own animating logic to walk that path. 

On Sun, Dec 16, 2012 at 3:47 PM, Jose Martinez <jmarti...@yahoo.com> wrote:

I do not see them as different approaches to the same task.  They seem to me to be different approaches to different tasks.  PathTransition is moving an object through the screen along a path along a time line.  AnimationTimer for the Towers is just a fancy loop that reminds the tower to shoot very frequently.  I would not, for example, use an AnimationTimer to move a Node along a path nor would I use a Transition for the purposes of executing some code very frequently.

If the Enemies were shooting back for example, then their "pulse" method would also be called during the main game loop.  Transitions are typically for altering Nodes as they appear on the screen along a time line.  AnimationTimer just allows you to execute code very frequently.  IMO they can work hand in hand without interfering with each other.

 

thanks

jose

---

From: Daniel Zwolenski <zon...@gmail.com>

To: Jose Martinez <jmarti...@yahoo.com>
Cc: Richard Bair <Richar...@oracle.com>; "fx-g...@googlegroups.com" <fx-g...@googlegroups.com>
Sent: Saturday, December 15, 2012 11:33 PM
Subject: Re: Latest code updates - AnimationTimer and other ideas

[Daniel Zwolenski]

Yea, the challenges I'm outlining definitely aren't in your code - you did exactly what I think should have been done within the design of what's there (and exactly what I would have done). 

I'm more just raising the question regarding the bigger design (i.e. where should an Enemy/Tower's animation/update logic be and how should it be started/stopped/paused, etc) and whether we think this works or not. It might be fine, but I figure it's a good time to raise some of the issues now before we get too far down the path. I'm leaning towards the central Game clock, with things implementing a PulseListener and doing all their updates in a pulse method - i.e. the good old fashioned game-loop. I was hoping that JFX Transitions could be leveraged though and keen to explore if/how still.  

Kids take precedence always, that's their role: to stop us getting sidetracked on trivial things like re-inventing Java on the desktop, and making us focus on more important things like peek-a-boo. I don't have any of my own but I'm from a massive family with lots of babysitting duties. Enjoy :) 

On Mon, Dec 17, 2012 at 1:38 AM, <jmarti...@yahoo.com> wrote:

Dan,

Thanks for the feedback. Yeah I agree not to start animation on the Enemy's AnimatedImageNode until the level starts. I tried to do that but the child Enemy is not told when the level starts. This would involve a change in the Enemy's implementation.

I'll respond to the rest of the email later...my kid is in need of attention over here.

Jose

Sent via BlackBerry by AT&T

---

From: Daniel Zwolenski <zon...@gmail.com>

Date: Sun, 16 Dec 2012 23:07:09 +1100

To: Jose Martinez<jmarti...@yahoo.com>

Cc: Richard Bair<Richar...@oracle.com>; fx-g...@googlegroups.com<fx-g...@googlegroups.com>

[Daniel Zwolenski]

So here's my proposed changes:

Ones I hope are non-contentious: 

1. Make Level not abstract

2. Move Tower animation code (without really changing it) inside Tower class instead of having it in LevelPanel

3. Move Enemy animation code (without really changing it) inside Enemy class instead of having it in LevelPanel. Enemy will be passed a Path and then internally manage how it animates along this Path. 

Ones that might be more contentious (i.e. one's I am less sure about myself): 

4. Add a PulseListener interface and make Game have an addPulseListener. Have a single AnimationTimer within Game that calls pulse on all the registered listeners as needed. Move all pausing/starting/stopping logic into this so to pause you just call Game.pause, which stops the AnimationTimer, which stops calls to pulse, which pauses the Game.  

5. Remove all Animation/Transitions and convert these into pulse logic. So an Enemy will be passed a Path to follow and on each pulse will manually move a little further along that path. 

 

I'm going with the 24 hours to comment policy - if I don't hear any objections in that time I will start coding it. I'll code it up on my fork so you can all review before we merge back but I'd definitely prefer not to put the effort in if anyone thinks up front this is not the way to go. 

Cheers, 

Dan

[Daniel Zwolenski]

Makes sense to me.

Why doesn't Animation have a setAnimationTimer() on it? Seems logical and would make our life easy here (and I have looked for that before for things like scene transitions) - deliberate design or oversight?

On Tue, Dec 18, 2012 at 7:20 AM, Richard Bair <richar...@oracle.com> wrote:

I doubt it would have any impact on performance. Any overhead in method calls is going to be at least a wash compared to the overhead of running the animations in the FX engine, so that shouldn't be a problem. The main benefit to having a single game loop that is driving transitions (or other pulse listeners) in my mind is the clarity and simplicity. You know at any given time what is driving the game loop, you know where to insert logic (for example, a Physics engine always wants to have a main game loop driving it), and it is easy to pause / restart all the game animations in a single place.

Richard

On Dec 17, 2012, at 11:07 AM, Jose Martinez <jmarti...@yahoo.com> wrote:

5) If we still have to use a PathTransition then I fail to see the purpose/benefit of using the AnimationTimer for moving the Enemy.  I fail to see an architectural benefit and a perf benefit.

So we either have a dozen Enemies each with their own PathTransition that is individually playing, or an AnimationTimer that pulses each Enemy and reminds it to move ahead along its path.  It seems to me that the latter has more method calls per pulse and such that might cause a perf hit instead of a perf benefit.

thanks

jose

---

From: Richard Bair <richar...@oracle.com>
To: Jose Martinez <jmarti...@yahoo.com>
Cc: Daniel Zwolenski <zon...@gmail.com>; "fx-g...@googlegroups.com" <fx-g...@googlegroups.com>
Sent: Monday, December 17, 2012 10:37 AM

Subject: Re: Latest code updates - AnimationTimer and other ideas

Hi guys,

There should be no problem with using a PathTransition manually. I think the only gotcha is that events (finish events) don't fire when moving the play head. But you should be able to move a guy along the PathTransition manually.

Ones I hope are non-contentious: 

1. Make Level not abstract

I have no opinion on this.

2. Move Tower animation code (without really changing it) inside Tower class instead of having it in LevelPanel

Yes, this was the next step I just didn't have time to get to.

3. Move Enemy animation code (without really changing it) inside Enemy class instead of having it in LevelPanel. Enemy will be passed a Path and then internally manage how it animates along this Path. 

Sounds good.

Ones that might be more contentious (i.e. one's I am less sure about myself): 

4. Add a PulseListener interface and make Game have an addPulseListener. Have a single AnimationTimer within Game that calls pulse on all the registered listeners as needed. Move all pausing/starting/stopping logic into this so to pause you just call Game.pause, which stops the AnimationTimer, which stops calls to pulse, which pauses the Game.  

I wanted to do this too. Having to keep two sets -- timers and animations -- is a pain and error prone. I wanted just a single game loop timer and drive (most) everything from that. I say most, because sometimes when you pause a game the little enemy feet keep moving but I don't care if ours do or not. Unless we have a space invaders version :-)

5. Remove all Animation/Transitions and convert these into pulse logic. So an Enemy will be passed a Path to follow and on each pulse will manually move a little further along that path. 

I'd reuse transitions wherever they are simpler, and just have a PulseListener adapter that you can pass any animation into and it will be driven from the main game loop.

Richard

[Jose Martinez]

Sounds good Rich.  Thanks for clearing that up.

jose

---

From: Richard Bair <richar...@oracle.com>

To: Jose Martinez <jmarti...@yahoo.com>

Cc: Daniel Zwolenski <zon...@gmail.com>; "fx-g...@googlegroups.com" <fx-g...@googlegroups.com>

Sent: Monday, December 17, 2012 3:20 PM

Subject: Re: Latest code updates - AnimationTimer and other ideas

I doubt it would have any impact on performance. Any overhead in method calls is going to be at least a wash compared to the overhead of running the animations in the FX engine, so that shouldn't be a problem. The main benefit to having a single game loop that is driving transitions (or other pulse listeners) in my mind is the clarity and simplicity. You know at any given time what is driving the game loop, you know where to insert logic (for example, a Physics engine always wants to have a main game loop driving it), and it is easy to pause / restart all the game animations in a single place.

Richard

On Dec 17, 2012, at 11:07 AM, Jose Martinez <jmarti...@yahoo.com> wrote:

5) If we still have to use a PathTransition then I fail to see the purpose/benefit of using the AnimationTimer for moving the Enemy.  I fail to see an architectural benefit and a perf benefit.

So we either have a dozen Enemies each with their own PathTransition that is individually playing, or an AnimationTimer that pulses each Enemy and reminds it to move ahead along its path.  It seems to me that the latter has more method calls per pulse and such that might cause a perf hit instead of a perf benefit.

thanks

jose

---

From: Richard Bair <richar...@oracle.com>

To: Jose Martinez <jmarti...@yahoo.com>

Cc: Daniel Zwolenski <zon...@gmail.com>; "fx-g...@googlegroups.com" <fx-g...@googlegroups.com>
Sent: Monday, December 17, 2012 10:37 AM

Subject: Re: Latest code updates - AnimationTimer and other ideas

Hi guys,

There should be no problem with using a PathTransition manually. I think the only gotcha is that events (finish events) don't fire when moving the play head. But you should be able to move a guy along the PathTransition manually.

Ones I hope are non-contentious: 

1. Make Level not abstract

I have no opinion on this.

2. Move Tower animation code (without really changing it) inside Tower class instead of having it in LevelPanel

Yes, this was the next step I just didn't have time to get to.

3. Move Enemy animation code (without really changing it) inside Enemy class instead of having it in LevelPanel. Enemy will be passed a Path and then internally manage how it animates along this Path. 

Sounds good.

Ones that might be more contentious (i.e. one's I am less sure about myself): 

4. Add a PulseListener interface and make Game have an addPulseListener. Have a single AnimationTimer within Game that calls pulse on all the registered listeners as needed. Move all pausing/starting/stopping logic into this so to pause you just call Game.pause, which stops the AnimationTimer, which stops calls to pulse, which pauses the Game.  

I wanted to do this too. Having to keep two sets -- timers and animations -- is a pain and error prone. I wanted just a single game loop timer and drive (most) everything from that. I say most, because sometimes when you pause a game the little enemy feet keep moving but I don't care if ours do or not. Unless we have a space invaders version :-)

5. Remove all Animation/Transitions and convert these into pulse logic. So an Enemy will be passed a Path to follow and on each pulse will manually move a little further along that path. 

[Daniel Zwolenski]

Yea, or that solution, or anything that makes a more consistent link between AnimationTimer and Animation. At the moment AnimationTimer feels weird and out on its own. For example why is there no AnimationTimer.runningProperty or similar that I can just bind the pause property of game to. It's not so much a is-there-need for stuff on AnimationTimer rather why do we have two distinct/disjoint concepts around animating - doesn't look like AnimationTimer fought for it's existence but kind of snuck in the back door when no one was looking and now is claiming squatters-rights ;)

But we can make it work - just noting an API inelegance as we go. I'll leave it with you to do-or-do-not as you think appropriate. 

 

On Tue, Dec 18, 2012 at 8:14 AM, Richard Bair <richar...@oracle.com> wrote:

I haven't seen the need (when in doubt, leave it out -- let the need manifest itself). What I found odd though was that AnimationTimer wasn't an animation -- and used "start" instead of "play". Otherwise you can just put them in a ParallelTransition and use that to drive the universe.

[Richard Bair]

> Yea, or that solution, or anything that makes a more consistent link between AnimationTimer and Animation. At the moment AnimationTimer feels weird and out on its own. For example why is there no AnimationTimer.runningProperty or similar that I can just bind the pause property of game to. It's not so much a is-there-need for stuff on AnimationTimer rather why do we have two distinct/disjoint concepts around animating - doesn't look like AnimationTimer fought for it's existence but kind of snuck in the back door when no one was looking and now is claiming squatters-rights ;)

More like a disagreement over what it should be. I got the name I wanted, anyway :-). We should file a JIRA to see if we can make AnimationTimer an Animation rather than being separate.

[Jose Martinez]

Ok so from the list of 5 things Dan pointed out, does anybody want to tackle any of them?  So that we do not step on each other's toes we should agree on who should do what.

 

I will contribute about 2 hours of programming tonight, so let me know if I should take care of any of these, else I'll do vector work that will not interfere with any of these.

thanks

jose

---

From: Daniel Zwolenski <zon...@gmail.com>

To: Richard Bair <richar...@oracle.com>
Cc: Jose Martinez <jmarti...@yahoo.com>; "fx-g...@googlegroups.com" <fx-g...@googlegroups.com>
Sent: Monday, December 17, 2012 4:30 PM

--
 
 

[Daniel Zwolenski]

I'm trying to squeeze in most of them when my boss (that would be me) isn't looking today. They are all a bit inter-related. 

I'll focus on getting the game pulse in there and move a couple of small things to use this model and then maybe you could pick it up from there (e.g. move AnimatedSprite to the pulse based model)? 

I might have some more time tomorrow to put in on it if I get up real early - sleep is such a waste of good coding time ;)

 

[Daniel Zwolenski]

Just checked in a few more cleanups (Towers are shooting again). I had a few work distractions today and didn't get enough time to make everything as solid as I would like but I did get most of it working. It could do with some good solid reviewing though to see what you guys are happy with and not (and I should review it myself some more when I get some time). 

This is all in my fork - review and if you're happy we can pull into the main repo or can make changes before that happens. How about if no negative comments within 2 days, I'll merge it myself. 

Main thing is I introduced the GamePulse concept, so Game has an AnimationTimer and calls pulse() on its listeners as needed. 

To do this there were a fair few things I had to change:

• I added a Projectile class to represent bullets - this was a loose concept in Richard's code but I get the feeling he was heading that way
  
• I've moved all processing/updating logic for Towers, Enemies and Projectiles into their respective classes and made them do this logic when pulse is called
  
• I gave each of these a link back to their Level so they could interact with it (e.g. find enemies to shoot at)
  
• I've opened up methods for interacting with the Level (e.g. addEnemy, addTower, addProjectile, findEnemiesInArea)
  
• I moved spawning enemy logic inside Wave, and Wave also implements pulse - this whole area is rough still and end of wave/level is not well handled 
  
• I took out the Transitions at this stage just to get it working, so Enemies move in a straight line. Need to spend some time working out how to use a Transition without calling play (Richard says it's possible, I haven't really looked yet). 

Other comments:

• I think the GamePulse idea works well - lots to improve but conceptually seems to work.
  
• Obvious hole is the path routing for enemies and also the AnimatedSprite doesn't work off the pulse yet - just lack of time.
• My other math for projectile path and speed calculations is all pretty bad too - needs some work  
• I made Game call pulse on Level and then Level loop and call pulse on its kids rather than the kids being added to the game directly, seemed easier when cleaning up 
  
• I feel like we are getting close to needing a common base class for sprites for things like setLevel and getCentre. 
• I've not been real consistent on observable properties vs regular old values - feel free to clean up (I'm not overly sure when to use a property and when not)
• I think Richard was not real consistent on the use of layoutX vs translateX and I'm not sure when to use which and what difference there would be in practice 

Let me know thoughts.

I'm unlikely to do anything more on this in the next two to three days but should be able to answer questions, etc. 

[jmarti...@yahoo.com]

I'll take a look at the tonight.

Jose

Sent via BlackBerry by AT&T

---

From: Daniel Zwolenski <zon...@gmail.com>

Date: Tue, 18 Dec 2012 23:55:47 +1100

To: Jose Martinez<jmarti...@yahoo.com>

Cc: Richard Bair<richar...@oracle.com>; fx-g...@googlegroups.com<fx-g...@googlegroups.com>

[Richard Bair]

Just issue the pull request and then we can do a code review and pull it when ready.

--
 
 

[Jose Martinez]

Looked through the code.  Looks good to me.  We have to do something now about properly moving the enemy through his path.

The speed of a unit must be predictable and reproducible.  That is to say that if SomeEnemy moves at a certain rate, then that rate must be reproduced for future levels with varying path lengths.  To properly do this you need to know your base speed and the length of the path that you are traversing.  I did not discover a way to pull out the path distance from a Path object, do you know of a way?  The way I did it in previous project was to have a MapPath class that kept track of the distance of the Path for that level.  The distance was calculated using the summations of all the points used to make the Path.  So given a path distance (in pixels) and an Enemy base speed (in pixels per sec), I could figure out how long it should take to traverse through a given path of a level.

So now when pulse is called on an Enemy should know how much time passed since it started moving and know exactly where I should be along that Path.

- pathTranstion.interpolate((timeSinceStart - now)/pathDurationLength);

If this is the direction we go then we might want to have an Enemy.startMoving() method that would capture the timeSinceStart, else it would have to be captured from pulse(), where it would have to check if this is the first time pulse is being called by keeping state.

thanks

jose

[Daniel Zwolenski]

The logic we need for this should be in the Transiton classes. Richard hinted that we might still be able to use them directly (ie internally have a transition in Enemy and when pulse is called, call the equivalent pulse method on the transition). 

If not, looks like the animation code got open sourced today! Might be worth a bit of peek. 

I'm happy with whatever works (and won't be looking at it for a few days at least) so long as the solution doesn't leak outside of the Enemy class, ie it's been told where to go, it's up to it to work how to get there. 

--
 
 

[Richard Bair]

I had this problem too (what is the length of the path?). I thought if the path was always made up of move-to's, then it would be easy. I am not a math wiz, but I wonder if CubicCurveTo & such are also hard to compute?

Richard

--
 
 

[jmarti...@yahoo.com]

Yeah in the example line I assumed a PathTransition. With pathTransition the interpolate method let's you move along the path.

I can work on this tomorrow using a PathTransition and interpolate to move along in the pulse. Can Dan's new code be merged?

Thanks

Jose

Sent via BlackBerry by AT&T

---

From: Daniel Zwolenski <zon...@gmail.com>

Sender: fx-g...@googlegroups.com

Date: Wed, 19 Dec 2012 14:56:03 +1100

To: Jose Martinez<jmarti...@yahoo.com>

Cc: fx-games google group<fx-g...@googlegroups.com>

Subject: Re: Latest code updates - AnimationTimer and other ideas

--
 
 

[jmarti...@yahoo.com]

The lineTo's are easy to calculate distance and the curveTo elements I avoided and instead used mathematical expressions to define curvy Paths. Math expressions are easier to work with also because you can design them on a graph plotter.

We can avoid curves all together and go with lineTo's exclusively, at least in the beginning.

Jose

Sent via BlackBerry by AT&T

---

From: Richard Bair <richar...@oracle.com>

Sender: fx-g...@googlegroups.com

Date: Tue, 18 Dec 2012 19:57:52 -0800

To: Jose Martinez<jmarti...@yahoo.com>

Cc: fx-games google group<fx-g...@googlegroups.com>

Subject: Re: Latest code updates - AnimationTimer and other ideas

--
 
 

[Daniel Zwolenski]

One thing to keep in the back of our minds for all of this is that "jerky" animations (as opposed to poor rendering) seems to be the common complaint with respect to JFX "performance". If we ditch all the transition code it could either be a bad thing (in that we are no longer testing the transitions) or a good thing (in that if our resulting code is jerky or not, it helps narrow down the areas in JFX that cause problems). 

I'm thinking that once we get the actual game play working that it would be cool to have animated windows for things like level complete, etc, much in the vein of Bloons (where text flies, morphs shapes, etc), so maybe that will be a useful test bed for the transition stuff as well. 

Just mentioning it in passing, and for future reference when we are considering performance aspects and what works/doesn't. I think we should push ahead with whatever works best for the game. 

--
 
 

[Richard Bair]

For interest sake, I'd be shocked, SHOCKED I say! if it turns out that jerkiness is affected by transitions. Its almost certainly in Glass/Prism timing issues (waiting for vsync and swapping buffers).

--
 
 

[Daniel Zwolenski]

ok, that is good to know! So maybe us building without Transitions is a good thing as it will narrow the target areas when we look at performance. 

[Jose Martinez]

For VectorEnemy I think the shaking, which only appeared at the very last iteration of that class, is being caused by the bounds changing by 1 or 2 pixels due to all the movement the electric lines.  I suspect this is easily fixable using Panes with prefWidth set but I wanted to implement using Canvas, but didn't do it yet.

jose

---

From: Daniel Zwolenski <zon...@gmail.com>

To: Richard Bair <richar...@oracle.com>
Cc: jose martinez <jmarti...@yahoo.com>; "fx-g...@googlegroups.com" <fx-g...@googlegroups.com>
Sent: Wednesday, December 19, 2012 12:31 AM

--
 
 

[Jose Martinez]

Hello,

Pulled from Dan's most recent fork and added the changes listed below.  Committed to my own fork, but was not able to issue a pull request.  Maybe because there is an outstanding request?

- Moved Path from LevelPanel variable to a Wave variable. So LevelPanel no longer holds an instance to Path.
- LevelPanel gets Wave's from setter method instead of constructor.
- Path is still created in FirstLevel but is passed to Wave along with the path distance.
- Wave sets the Path and path distance onto the Enemy
- Enemy uses speed variable and path distance to figure out what the duration of the PathTransition should be.
- Enemy moves itself along its Path in the pulse method using PathTransition's interpolate method.

With these changes the units now move through the Path using Dan's last fork.  Once problem that I did have was that I was not able to use PathTransition's interpolate method until I called the play method first.  After calling the play method I paused it, then I was able to use interpolate without a problem.  You can see this is in Enemy's pulse method.  Anyway to use PathTransition's interpolate method without needing to call play/pause on it?

 

thanks

jose

---

From: Jose Martinez <jmarti...@yahoo.com>
To: "fx-g...@googlegroups.com" <fx-g...@googlegroups.com>
Sent: Wednesday, December 19, 2012 8:23 AM

[Daniel Zwolenski]

Hmmm, we probably should have merged these changes first - didn't realise they weren't in the main repo. 

--