<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.E-MailFormatvorlage18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=DE link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Of source strict typing is much better. But the major target is
to save time. You will lose time without strict typing, sure. But you always have
to decide which will cost more time. And I think a universal tween engine with
string properties can save more time than you will lose with those. (The
little performance differences are not so important to me.)<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>But I'm not really sure. On one hand every other possibility at
the moment needs more work at the beginning, on the other hand I hate untyped
code, too. Tricky :(<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Von:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
golist-bounces@goasap.org [mailto:golist-bounces@goasap.org] <b>Im Auftrag von </b>John
Grden<br>
<b>Gesendet:</b> Mittwoch, 7. Mai 2008 14:08<br>
<b>An:</b> Mailing list for the Go ActionScript Animation Platform<br>
<b>Betreff:</b> Re: [Golist] This looks a bit better as far as syntax<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>The thing about strict / strong
typing is that you gain performance benefits, coding benefits, compiling
security as well as control in a development environment where you have several
devs working on the same project.<br>
<br>
Now, in the api I'm developing, I'm starting to see how easy it would be to
abstract the properties class so that if you knew what properties you would
ever want to manipulate, you could create your own properties class. For
the most part, if we really think about it, you can create classes ( or maybe
just one big one ) for DisplayObjects to start with. If you used Fuse
like I did for sequencing events more than actual tweening, you can certainly
create your own properties class for those as well. I mean, it makes too
much sense especially in light of what you gain in terms of what I mentioned
above.<br>
<br>
It doesn't cut you off from doing anything at all, and you gain quite a
bit. The cost is adding 1 properties class 1 time.<br>
<br>
Thoughts?<o:p></o:p></p>
<div>
<p class=MsoNormal>On Wed, May 7, 2008 at 12:44 AM, Sebastian Weyrauch <<a
href="mailto:go@tweego.org">go@tweego.org</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>Hi,</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'>think this method of John is
really cool too. I hate string properties too. But as you mentioned: For
universal handling this is no real possibility :( If the advantage is much
bigger than the disadvantage, you can give up strict typing, at least in my
eyes.</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'>Maybe you're right. A universal
tween class can not be that good as specialized classes. But I think it can be
really hard to know and use several tween classes. And all popular tween classes
are universal tween classes. But perhaps this will change in future. We will
see.</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'>best regards</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'>sebastian</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<div>
<div style='border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0cm 0cm 0cm;
border-color:-moz-use-text-color -moz-use-text-color'>
<p><b><span style='font-size:10.0pt'>Von:</span></b><span style='font-size:
10.0pt'> <a href="mailto:golist-bounces@goasap.org" target="_blank">golist-bounces@goasap.org</a>
[mailto:<a href="mailto:golist-bounces@goasap.org" target="_blank">golist-bounces@goasap.org</a>]
<b>Im Auftrag von </b>Moses Gunesch<br>
<b>Gesendet:</b> Mittwoch, 7. Mai 2008 00:06<br>
<b>An:</b> Mailing list for the Go ActionScript Animation Platform<br>
<b>Betreff:</b> Re: [Golist] This looks a bit better as far as syntax</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p> <o:p></o:p></p>
<p>Hehe, sorry. And they let me write for a book! ;)<o:p></o:p></p>
<div>
<p>Let me try again....<o:p></o:p></p>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p><u>Turn ons:</u> What you're doing is better for strict typing because
the properties are real properties – that is cool. I like how you have
x() etc., that's really cool. In mine you had to do properties as strings like
"x".<o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p><u>Turn offs:</u> I'm starting to lean against multi-property
tween classes in general. Because, it's easy to forget how complex
just ONE tween can be. Like, think of a color tween or a filter tween –
multiple properties in arrays, nested in subproperties of display objects...
gets hairy. Start values and relative values are another can of worms.<o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p>Lately I've been thinking that<i> </i>a tween instance is more like an
atom than a molecule. That's why I'm now gravitating back toward
individual-property tween classes. That, and OverlapMonitor would be able to
handle every property individually. <o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p>Have not built this out though.... <o:p></o:p></p>
</div>
<div>
<p>But I'm wondering if there would some way to do that cool property syntax
thing you're doing, but at the PlayableGroup level?<o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p>- m<o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
<div>
<div>
<p>On May 6, 2008, at 4:38 PM, John Grden wrote:<o:p></o:p></p>
</div>
<p style='margin-bottom:12.0pt'><o:p> </o:p></p>
<p style='margin-bottom:12.0pt'>So I'm confused a bit -seems like you said you
were leaning towards 1 property per tween that exists, but you like what I'm
doing with that last code sample<br>
<br>
LOL I know I missed something<br>
<br>
I think that I started to get what you meant though - having those apart of a
PlayableGroup etc is essentially what we end up with, is that about right?<o:p></o:p></p>
<div>
<p>On Tue, May 6, 2008 at 3:17 PM, Moses Gunesch <<a
href="mailto:moses@goasap.org" target="_blank">moses@goasap.org</a>> wrote:<o:p></o:p></p>
<div>
<p>Yeah that's good. I created a system called OpenTween – don't think I
ever posted it though because I wasn't sure I liked the abstraction layer of
putting a ton of information and functionality into property classes which is
what happened when I tried this.<o:p></o:p></p>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p>My property inputs were<o:p></o:p></p>
</div>
<div>
<div>
<p> propName: <span style='color:#373737'>String</span>, <o:p></o:p></p>
</div>
<div>
<p> endVal: *=<span style='color:#7F0055'>null</span>, <o:p></o:p></p>
</div>
<div>
<p> endValRelative: <span style='color:#373737'>Boolean</span>=<span
style='color:#7F0055'>false</span>, <o:p></o:p></p>
</div>
<div>
<p> startVal: *=<span style='color:#7F0055'>null</span>, <o:p></o:p></p>
</div>
<div>
<p> startValRelative: <span style='color:#373737'>Boolean</span>=<span
style='color:#7F0055'>false</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p>Then I had this functionality in there from Fuse, that lets you omit either start
or end and it will figure it out. That's probably why it got
complicated. (I will share OpenTween if you want.)<o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p>Anyway yeah I think there is something to a multi-property approach for
sure, but I've been leaning back toward just extending LinearGo in the simplest
way possible – one property per tween class. <o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p><b>Here is why:</b> if every single property were in a separate tween class,
OverlapMonitor works the best in that it can allow just one property to be
paused, stopped and so on. That's how ZigoEngine worked, it atomized every
tween internally. I've been thinking PlayableGroup could be extended to handle
multi-prop tweens by creating separate tween instances, then it could let you
drill into them to grab children by property etc. <o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p>One could argue that it's slower to not block all similar tweens, but it
also provides more control and is less abstract, and I've found that in real
practice there are usually only a very small number of "blocked"
tweens at once... pretty soon you want to change delay/duration/easing on one
property or another and you end up with a group anyway.<o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p>That said, I'd love to see your concept taken all the way John...!<o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p>:-)<o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
</div>
<div>
<p> <o:p></o:p></p>
<div>
<div>
<div>
<div>
<p>On May 6, 2008, at 3:54 PM, John Grden wrote:<o:p></o:p></p>
</div>
<p> <o:p></o:p></p>
</div>
</div>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<div>
<div>
<p><b>Was this:</b><br>
tween_0 = new Tween3D(target, 1, Equations.easeOutCubic);<br>
tween_0.x = 0;<br>
tween_0.y = 50;<br>
tween_0.rotationZ = 0;<br>
sequence.addStep(tween_0);<br>
<br>
sequence.lastStep.advance = new OnDurationComplete(.2); // advance
early/overlap<br>
tween_0b = new Tween3D(target, 1, Equations.easeOutCubic);<br>
tween_0b.z = 200;<br>
sequence.addStep(tween_0b, true); // 2nd param groups it with previous step.
param is "addToLastStep"<br>
<br>
tween_1 = new Tween3D(target, 1, Equations.easeOutCubic);<br>
tween_1.x = -10;<br>
tween_1.y = 85;<br>
tween_1.rotationZ = 15;<br>
sequence.addStep(tween_1);<br>
sequence.lastStep.advance = new OnDurationComplete(.25); // advance
early/overlap<br>
<br>
tween_2 = new Tween3D(target, 1, Equations.easeOutBounce);<br>
tween_2.rotationX = 0;<br>
tween_2.rotationY = 0;<br>
sequence.addStep(tween_2);<br>
<br>
<b>Is now this:</b><br>
<br>
tween_0 = new Tween3D(target, [Go3D.x(0), Go3D.y(50), Go3D.rotationZ(0)], 1,
Equations.easeOutCubic);<br>
sequence.addStep(tween_0);<br>
sequence.lastStep.advance = new OnDurationComplete(.2); // advance
early/overlap<br>
<br>
tween_0b = new Tween3D(target, [Go3D.z(200)], 1, Equations.easeOutCubic);<br>
sequence.addStep(tween_0b, true); // 2nd param groups it with previous step.
param is "addToLastStep"<br>
<br>
tween_1 = new Tween3D(target, [Go3D.x(-10), Go3D.y(85), Go3D.rotationZ(15)], 1,
Equations.easeOutCubic);<br>
sequence.addStep(tween_1);<br>
sequence.lastStep.advance = new OnDurationComplete(.25); // advance
early/overlap<br>
<br>
tween_2 = new Tween3D(target, [Go3D.rotationX(0), Go3D.rotationY(0)], 1,
Equations.easeOutBounce);<br>
sequence.addStep(tween_2);<br clear=all>
<br>
<br>
I'm still thinking about this approach, but thought I would throw it out to you
guys to see what you thought. Right now, there's static methods in Go3D
that return a Go3Dproperty. Tween3D has an array called propertyChanges
and if there is an array in the propertyChanges argument, I just set it
straight away - no parsing required. It's all ready to go and is filled
with Go3DProperty objects.<br>
<br>
Thoughts?<br>
-- <o:p></o:p></p>
</div>
</div>
<p>[ JPG ] _______________________________________________<br>
GoList mailing list<br>
<a href="mailto:GoList@goasap.org" target="_blank">GoList@goasap.org</a><br>
<a href="http://goasap.org/mailman/listinfo/golist_goasap.org" target="_blank">http://goasap.org/mailman/listinfo/golist_goasap.org</a><o:p></o:p></p>
</blockquote>
</div>
<p> <o:p></o:p></p>
</div>
</div>
<p style='margin-bottom:12.0pt'><br>
_______________________________________________<br>
GoList mailing list<br>
<a href="mailto:GoList@goasap.org" target="_blank">GoList@goasap.org</a><br>
<a href="http://goasap.org/mailman/listinfo/golist_goasap.org" target="_blank">http://goasap.org/mailman/listinfo/golist_goasap.org</a><o:p></o:p></p>
</div>
<p><br>
<br clear=all>
<br>
-- <br>
[ JPG ] _______________________________________________<br>
GoList mailing list<br>
<a href="mailto:GoList@goasap.org" target="_blank">GoList@goasap.org</a><br>
<a href="http://goasap.org/mailman/listinfo/golist_goasap.org" target="_blank">http://goasap.org/mailman/listinfo/golist_goasap.org</a><o:p></o:p></p>
</div>
<p> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
_______________________________________________<br>
GoList mailing list<br>
<a href="mailto:GoList@goasap.org">GoList@goasap.org</a><br>
<a href="http://goasap.org/mailman/listinfo/golist_goasap.org" target="_blank">http://goasap.org/mailman/listinfo/golist_goasap.org</a><o:p></o:p></p>
</div>
<p class=MsoNormal><br>
<br clear=all>
<br>
-- <br>
[ JPG ] <o:p></o:p></p>
</div>
</body>
</html>