Re: Animation Engine: speed tips
Here is a short video of a really nice ball animation of the Earth’s Carbon Cycle - which is the sort of thing I’d like to make a series of animations / interactive simulations about. There a re a few more than 30-40 moving balls here - but they are more or less dots…. https://www.youtube.com/watch?v=dwVsD9CiokY I wonder how many particles can be animated like this in Livecode... On 2 Jul 2020, 20:53 +0100, David Bovill , wrote: > That's inspired me :) > > I think it may be possible to do what I want in Livecode - which would be > great. Thanks Alex and Bernd :) > > > On Thu, 2 Jul 2020 at 20:36, Alex Tweedly via use-livecode > > wrote: > > > > > > On 01/07/2020 02:52, J. Landman Gay via use-livecode wrote: > > > > Did you use acceleratedRendering? Set it to true and set the layermode > > > > of each moving object to dynamic. I'd be curious to see if there's a > > > > difference. > > > > > > > > > > > Hadn't tried those until now. There is a difference - but not the kind > > > I'd hoped for :-) > > > > > > Full script is below with detailed time, but the summary is: > > > - acceleratedRendering made things much worse (50% to 90% slower) > > > - dynamic layerMode made things a little bit better (5% to 15%). > > > > > > If the circle was moving over a plain background, improvement was only > > > 5%-ish, while if moving over multiple other shapes, it gave a better > > > improvement. > > > > > > Here's the full snippet of the script involved (other cases obvious :-) > > > > > > > set the acceleratedRendering of this stack to false > > > > set the layermode of grc "g1" to "static" > > > > > > > > repeat 3 times > > > > put 100,400 into tmp > > > > put the millisecs into tim1 > > > > repeat 100 times > > > > add 1 to item 1 of tmp > > > > set the loc of grc "g1" to tmp > > > > wait 0 with messages > > > > end repeat > > > > put the acceleratedRendering of this stack && \ > > > > the layermode of grc "g1" \ > > > > && the millisecs-tim1 after gLog > > > > end repeat > > > > put CR after gLog > > > > > > Here are the times for each of the cases, moving 100 times > > > > > > false static 192 > > > false static 154 > > > false static 155 > > > > > > true static 285 > > > true static 332 > > > true static 249 > > > > > > true dynamic 265 > > > true dynamic 255 > > > true dynamic 309 > > > > > > false dynamic 131 > > > false dynamic 134 > > > false dynamic 149 > > > > > > Alex. > > > > > > > > > ___ > > > use-livecode mailing list > > > use-livecode@lists.runrev.com > > > Please visit this url to subscribe, unsubscribe and manage your > > > subscription preferences: > > > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Animation Engine: speed tips
That's inspired me :) I think it may be possible to do what I want in Livecode - which would be great. Thanks Alex and Bernd :) On Thu, 2 Jul 2020 at 20:36, Alex Tweedly via use-livecode < use-livecode@lists.runrev.com> wrote: > > On 01/07/2020 02:52, J. Landman Gay via use-livecode wrote: > > Did you use acceleratedRendering? Set it to true and set the layermode > > of each moving object to dynamic. I'd be curious to see if there's a > > difference. > > > > > Hadn't tried those until now. There is a difference - but not the kind > I'd hoped for :-) > > Full script is below with detailed time, but the summary is: > - acceleratedRendering made things much worse (50% to 90% slower) > - dynamic layerMode made things a little bit better (5% to 15%). > > If the circle was moving over a plain background, improvement was only > 5%-ish, while if moving over multiple other shapes, it gave a better > improvement. > > Here's the full snippet of the script involved (other cases obvious :-) > > > set the acceleratedRendering of this stack to false > >set the layermode of grc "g1" to "static" > > > >repeat 3 times > > put 100,400 into tmp > > put the millisecs into tim1 > > repeat 100 times > > add 1 to item 1 of tmp > > set the loc of grc "g1" to tmp > > wait 0 with messages > > end repeat > > put the acceleratedRendering of this stack && \ > > the layermode of grc "g1" \ > > && the millisecs-tim1 after gLog > >end repeat > >put CR after gLog > > Here are the times for each of the cases, moving 100 times > > false static 192 > false static 154 > false static 155 > > true static 285 > true static 332 > true static 249 > > true dynamic 265 > true dynamic 255 > true dynamic 309 > > false dynamic 131 > false dynamic 134 > false dynamic 149 > > Alex. > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Animation Engine: speed tips
On 01/07/2020 02:52, J. Landman Gay via use-livecode wrote: Did you use acceleratedRendering? Set it to true and set the layermode of each moving object to dynamic. I'd be curious to see if there's a difference. Hadn't tried those until now. There is a difference - but not the kind I'd hoped for :-) Full script is below with detailed time, but the summary is: - acceleratedRendering made things much worse (50% to 90% slower) - dynamic layerMode made things a little bit better (5% to 15%). If the circle was moving over a plain background, improvement was only 5%-ish, while if moving over multiple other shapes, it gave a better improvement. Here's the full snippet of the script involved (other cases obvious :-) set the acceleratedRendering of this stack to false set the layermode of grc "g1" to "static" repeat 3 times put 100,400 into tmp put the millisecs into tim1 repeat 100 times add 1 to item 1 of tmp set the loc of grc "g1" to tmp wait 0 with messages end repeat put the acceleratedRendering of this stack && \ the layermode of grc "g1" \ && the millisecs-tim1 after gLog end repeat put CR after gLog Here are the times for each of the cases, moving 100 times false static 192 false static 154 false static 155 true static 285 true static 332 true static 249 true dynamic 265 true dynamic 255 true dynamic 309 false dynamic 131 false dynamic 134 false dynamic 149 Alex. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Animation Engine: speed tips
Thank you Mark, Glad you enjoyed it. If you feel like it you could set the markerPoints of graphic gSand to a ball, still running at 22 frames/sec with 500 of them, filled. -- 0,-13 3,-13 6,-12 8,-11 10,-9 12,-6 13,-3 13,0 13,3 12,6 10,9 8,11 6,12 3,13 0,13 -3,13 -6,12 -8,11 -10,9 -12,6 -13,3 -13,0 -13,-3 -12,-6 -10,-9 -8,-11 -6,-12 -3,-13 0,-13 - Kind regards Bernd > Mark Talluto via use-livecode Wed, 01 Jul 2020 20:55:00 -0700 > > This is completely awesome! Thank you Bernd. > > -Mark Talluto > Canela Software > > On Wed, Jul 1, 2020 at 8:27 AM Niggemann, Bernd via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > While not exactly what David asked for but on the topic of animating > > multiple objects with acceptable speed: > > > > http://forums.livecode.com/viewtopic.php?f=10=11726=sand#p56253 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Animation Engine: speed tips
This is completely awesome! Thank you Bernd. -Mark Talluto Canela Software On Wed, Jul 1, 2020 at 8:27 AM Niggemann, Bernd via use-livecode < use-livecode@lists.runrev.com> wrote: > While not exactly what David asked for but on the topic of animating > multiple objects with acceptable speed: > > http://forums.livecode.com/viewtopic.php?f=10=11726=sand#p56253 > > The original poster asked for "sand" particles that should have some sort > of collision detection and should react to a mouseDown to either attract > the objects or pushes them away. > > It uses _one_ polygon graphic and sets individual points of that graphic > (separated by an empty line). The points are just x,y coordinates and > markers make the visual objects of the moving parts. > > It manages to animate quite some number of objects depending on the size > of the markers and some other features that are optional (dropshadow, > ounteglow, markers filled and antialiasing) > > The stack is completely useless but perfect for a rainy day at home. > Depending on the complexity of the marker graphic it manages to animate > smoothly (frame rate 18 and up) from 150 to 1500 (small) objects (you can > change appearance while the objects are moving. > > Kind regards > Bernd > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Animation Engine: speed tips
While not exactly what David asked for but on the topic of animating multiple objects with acceptable speed: http://forums.livecode.com/viewtopic.php?f=10=11726=sand#p56253 The original poster asked for "sand" particles that should have some sort of collision detection and should react to a mouseDown to either attract the objects or pushes them away. It uses _one_ polygon graphic and sets individual points of that graphic (separated by an empty line). The points are just x,y coordinates and markers make the visual objects of the moving parts. It manages to animate quite some number of objects depending on the size of the markers and some other features that are optional (dropshadow, ounteglow, markers filled and antialiasing) The stack is completely useless but perfect for a rainy day at home. Depending on the complexity of the marker graphic it manages to animate smoothly (frame rate 18 and up) from 150 to 1500 (small) objects (you can change appearance while the objects are moving. Kind regards Bernd ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Animation Engine: speed tips
Alex, Eagerly awaiting news of your progress! — Scott Morrow Elementary Software (Now with 20% less chalk dust!) web https://elementarysoftware.com/ email sc...@elementarysoftware.com booth1-800-615-0867 -- > On Jun 30, 2020, at 6:40 PM, Alex Tweedly via use-livecode > wrote: > > Hi David, > > I had a quick look at this (for slightly selfish reasons - I will be doing > some simple animation soon, so this piqued my interest to look at it sooner > :-) > > [ all comments on performance or timing here are on an aging (2011) Macbook > Pro, LC 9.6.0 ] > > So, there's good news, and there's bad news :-) > > 1. Bad news. > > It is slow (surprisingly, disappointingly slow) to move graphic objects in > LC. Moving small simple objects (unfilled circle graphics <20 pixels across) > over an uncomplicated background. Each move takes between 1 and 2.6 msecs. > (Yes, that's for one object !!) > > [ Puts on 'grumpy old man' hat = that's about the same time as it took on my > old Atari ST - 34 years ago!! Where's Moore's Law when I need it :-). ] > > 2. Good news. > > Although disappointing performance, it is (probably) good enough for your > described example. Around 30 simple, small objects moving, 20 fps ~= 700ms > within a second; it should just be doable. > > 3. Bad News. > > You're on the edge !! The timings above were for moving objects in a simple, > tight loop. (see sample code below my sig.) You have a little bit of spare > CPU left over to handle overhead, object management, new co-ord calculation, > etc., but not very much. > > Animation Engine. > > It's a powerful library - has lots of good stuff to do fading, morphing, > collision detection, input constraint, color changes, animated scrolls > (bounce, overshoot, ...), and then it has two methods of just *moving* LC > controls. > > The 'classic' version requires the developer to set up a timer/loop handler, > and use the various aeMovexxx handlers; because of the timer handling it's > tricky and needs care from the developer. > > The other version is only for straight line moves (aeMoveTo); this is much > simpler to use, can handle multiple shapes moving in synch and does it very > efficiently. (The older equivalent was aeMoveLinear, which is deprecated). If > all your moving is (or can be cast into) using this version, you might have > no problems. Note Malte describes aeMoveTo as 'frame-perfect' - all the moves > done by aeMoveTo happen perfectly aligned by the (single) frame timer, so > moves can be precisely coordindated to start and/or finish at exactly the > same time. > > If it can't be, then you might think about adding new functionality to AE to > provide a similar capability , using the same single timer that aeMoveTo uses. > > My needs are slightly different:- > 1. linear and "hop" moves only (*) > 2. need to string together multiple moves within a 'frame-perfect' setting > > btw - this 'stringing together' is exactly what you would need for hand-drawn > curve following; you'd form a points-list from the hand-drawing, then > construct a series of linear moves along each edge. > > I decided the easiest way to achieve what I need was a simple > purpose-specific library, that has just these features. It's simple to use, > understand and debug - currently < 200 lines, and likely to finish up around > 250 lines by the time I'm done adding features. > > (*) What's a "hop" move? > Think of a child's board game (Ludo, S, ...) When you move a piece, > you don't (if you're playing with a child) usually just pick it up and move > it (say) 5 squares, instead you go "...1...2...3...4...5", while touching the > piece in or near each square in turn. That's a hop move (or a series of > hop-moves. :-) > > Anyway - I have that working now, so with luck I'll get a chance to work on > it this week and get it tidied up, and release a first version by the > weekend, so if you (or anyone) is interested they can try it out. > > Alex. > > Simple benchmark: > > I finished up with a pretty trivial example bit of code: > > > >put the loc of grc "g1" into tmp > >repeat 100 times > > add 1 to item 1 of tmp > > set the loc of grc "g1" to tmp > > wait 0 with messages > >end repeat > > Notes: > > 0. Graphic "g1" is a simple, small circle. > > 1. if the graphic wanders off screen (out of window) the time taken drops to > 0. > > 2. If you remove the "add 1 to item 1 of tmp" (i.e. the graphic remains in > the same place), then again the time drops to effectively 0. > > So with this simple code, I find that (on my aging Macbook Pro), those 100 > moves take between 125 and 275 ms (i.e. just about 1 to 2.5 ms per shape to > move). And that variation is easily matched against the complexity of the > surroundings the piece is moving through - if it moves over (or under) many > other graphic objects, it takes clearly
Re: Animation Engine: speed tips
Did you use acceleratedRendering? Set it to true and set the layermode of each moving object to dynamic. I'd be curious to see if there's a difference. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On June 30, 2020 8:43:25 PM Alex Tweedly via use-livecode wrote: Hi David, I had a quick look at this (for slightly selfish reasons - I will be doing some simple animation soon, so this piqued my interest to look at it sooner :-) [ all comments on performance or timing here are on an aging (2011) Macbook Pro, LC 9.6.0 ] So, there's good news, and there's bad news :-) 1. Bad news. It is slow (surprisingly, disappointingly slow) to move graphic objects in LC. Moving small simple objects (unfilled circle graphics <20 pixels across) over an uncomplicated background. Each move takes between 1 and 2.6 msecs. (Yes, that's for one object !!) [ Puts on 'grumpy old man' hat = that's about the same time as it took on my old Atari ST - 34 years ago!! Where's Moore's Law when I need it :-). ] 2. Good news. Although disappointing performance, it is (probably) good enough for your described example. Around 30 simple, small objects moving, 20 fps ~= 700ms within a second; it should just be doable. 3. Bad News. You're on the edge !! The timings above were for moving objects in a simple, tight loop. (see sample code below my sig.) You have a little bit of spare CPU left over to handle overhead, object management, new co-ord calculation, etc., but not very much. Animation Engine. It's a powerful library - has lots of good stuff to do fading, morphing, collision detection, input constraint, color changes, animated scrolls (bounce, overshoot, ...), and then it has two methods of just *moving* LC controls. The 'classic' version requires the developer to set up a timer/loop handler, and use the various aeMovexxx handlers; because of the timer handling it's tricky and needs care from the developer. The other version is only for straight line moves (aeMoveTo); this is much simpler to use, can handle multiple shapes moving in synch and does it very efficiently. (The older equivalent was aeMoveLinear, which is deprecated). If all your moving is (or can be cast into) using this version, you might have no problems. Note Malte describes aeMoveTo as 'frame-perfect' - all the moves done by aeMoveTo happen perfectly aligned by the (single) frame timer, so moves can be precisely coordindated to start and/or finish at exactly the same time. If it can't be, then you might think about adding new functionality to AE to provide a similar capability , using the same single timer that aeMoveTo uses. My needs are slightly different:- 1. linear and "hop" moves only (*) 2. need to string together multiple moves within a 'frame-perfect' setting btw - this 'stringing together' is exactly what you would need for hand-drawn curve following; you'd form a points-list from the hand-drawing, then construct a series of linear moves along each edge. I decided the easiest way to achieve what I need was a simple purpose-specific library, that has just these features. It's simple to use, understand and debug - currently < 200 lines, and likely to finish up around 250 lines by the time I'm done adding features. (*) What's a "hop" move? Think of a child's board game (Ludo, S, ...) When you move a piece, you don't (if you're playing with a child) usually just pick it up and move it (say) 5 squares, instead you go "...1...2...3...4...5", while touching the piece in or near each square in turn. That's a hop move (or a series of hop-moves. :-) Anyway - I have that working now, so with luck I'll get a chance to work on it this week and get it tidied up, and release a first version by the weekend, so if you (or anyone) is interested they can try it out. Alex. Simple benchmark: I finished up with a pretty trivial example bit of code: >put the loc of grc "g1" into tmp >repeat 100 times > add 1 to item 1 of tmp > set the loc of grc "g1" to tmp > wait 0 with messages >end repeat Notes: 0. Graphic "g1" is a simple, small circle. 1. if the graphic wanders off screen (out of window) the time taken drops to 0. 2. If you remove the "add 1 to item 1 of tmp" (i.e. the graphic remains in the same place), then again the time drops to effectively 0. So with this simple code, I find that (on my aging Macbook Pro), those 100 moves take between 125 and 275 ms (i.e. just about 1 to 2.5 ms per shape to move). And that variation is easily matched against the complexity of the surroundings the piece is moving through - if it moves over (or under) many other graphic objects, it takes clearly longer. Good luck. On 28/06/2020 01:09, David Bovill via use-livecode wrote: I made a quick test - creating and animating small graphic circles along a complex curve with many points. It works fine with one or two animated spheres but I’d like to be able to animate >30 and it
Re: Animation Engine: speed tips
Hi David, I had a quick look at this (for slightly selfish reasons - I will be doing some simple animation soon, so this piqued my interest to look at it sooner :-) [ all comments on performance or timing here are on an aging (2011) Macbook Pro, LC 9.6.0 ] So, there's good news, and there's bad news :-) 1. Bad news. It is slow (surprisingly, disappointingly slow) to move graphic objects in LC. Moving small simple objects (unfilled circle graphics <20 pixels across) over an uncomplicated background. Each move takes between 1 and 2.6 msecs. (Yes, that's for one object !!) [ Puts on 'grumpy old man' hat = that's about the same time as it took on my old Atari ST - 34 years ago!! Where's Moore's Law when I need it :-). ] 2. Good news. Although disappointing performance, it is (probably) good enough for your described example. Around 30 simple, small objects moving, 20 fps ~= 700ms within a second; it should just be doable. 3. Bad News. You're on the edge !! The timings above were for moving objects in a simple, tight loop. (see sample code below my sig.) You have a little bit of spare CPU left over to handle overhead, object management, new co-ord calculation, etc., but not very much. Animation Engine. It's a powerful library - has lots of good stuff to do fading, morphing, collision detection, input constraint, color changes, animated scrolls (bounce, overshoot, ...), and then it has two methods of just *moving* LC controls. The 'classic' version requires the developer to set up a timer/loop handler, and use the various aeMovexxx handlers; because of the timer handling it's tricky and needs care from the developer. The other version is only for straight line moves (aeMoveTo); this is much simpler to use, can handle multiple shapes moving in synch and does it very efficiently. (The older equivalent was aeMoveLinear, which is deprecated). If all your moving is (or can be cast into) using this version, you might have no problems. Note Malte describes aeMoveTo as 'frame-perfect' - all the moves done by aeMoveTo happen perfectly aligned by the (single) frame timer, so moves can be precisely coordindated to start and/or finish at exactly the same time. If it can't be, then you might think about adding new functionality to AE to provide a similar capability , using the same single timer that aeMoveTo uses. My needs are slightly different:- 1. linear and "hop" moves only (*) 2. need to string together multiple moves within a 'frame-perfect' setting btw - this 'stringing together' is exactly what you would need for hand-drawn curve following; you'd form a points-list from the hand-drawing, then construct a series of linear moves along each edge. I decided the easiest way to achieve what I need was a simple purpose-specific library, that has just these features. It's simple to use, understand and debug - currently < 200 lines, and likely to finish up around 250 lines by the time I'm done adding features. (*) What's a "hop" move? Think of a child's board game (Ludo, S, ...) When you move a piece, you don't (if you're playing with a child) usually just pick it up and move it (say) 5 squares, instead you go "...1...2...3...4...5", while touching the piece in or near each square in turn. That's a hop move (or a series of hop-moves. :-) Anyway - I have that working now, so with luck I'll get a chance to work on it this week and get it tidied up, and release a first version by the weekend, so if you (or anyone) is interested they can try it out. Alex. Simple benchmark: I finished up with a pretty trivial example bit of code: > put the loc of grc "g1" into tmp > repeat 100 times > add 1 to item 1 of tmp > set the loc of grc "g1" to tmp > wait 0 with messages > end repeat Notes: 0. Graphic "g1" is a simple, small circle. 1. if the graphic wanders off screen (out of window) the time taken drops to 0. 2. If you remove the "add 1 to item 1 of tmp" (i.e. the graphic remains in the same place), then again the time drops to effectively 0. So with this simple code, I find that (on my aging Macbook Pro), those 100 moves take between 125 and 275 ms (i.e. just about 1 to 2.5 ms per shape to move). And that variation is easily matched against the complexity of the surroundings the piece is moving through - if it moves over (or under) many other graphic objects, it takes clearly longer. Good luck. On 28/06/2020 01:09, David Bovill via use-livecode wrote: I made a quick test - creating and animating small graphic circles along a complex curve with many points. It works fine with one or two animated spheres but I’d like to be able to animate >30 and it slows to a crawl after 4 or 5. I tried setting the layer mode appropriately for all the objects - but I’m doing this on a new MacBook Pro - and it does not make a difference. Does anyone have an example stack with multiple animated objects that I can compare /
Re: OFFLIST Re: Animation Engine: speed tips
The first rule of OFFLIST is you don’t cc to the list. :-) But, I too an interested in what Malte is up to. Hope all things are going well for you Malte. Martin > On Jun 29, 2020, at 1:14 PM, Richard Gaskin via use-livecode > wrote: > > D'oh! My bad, I'd meant to not take up list space with this. > > But we all love Malte, and maybe he won't mind taking a moment to let us know > what he's working on lately. > > -- > Richard Gaskin > Fourth World Systems > > > Colin wrote: >> We’re all curious! >>> On Jun 29, 2020, at 9:26 AM, Richard Gaskin via use-livecode >> at lists.runrev.com> wrote: >>> On the use-livecode list you wrote: >>> > Hey Alex, >>> > >>> > Public Domain it is. I’ve set it free couple. of years back, as I am >>> > essentially no longer writing code. :-) Still following LiveCodes >>> > progress with interest though. :-) >>> > >>> > Cheers, >>> > >>> > Malte >>> If you're no coding, what are you up to these days? > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: OFFLIST Re: Animation Engine: speed tips
D'oh! My bad, I'd meant to not take up list space with this. But we all love Malte, and maybe he won't mind taking a moment to let us know what he's working on lately. -- Richard Gaskin Fourth World Systems Colin wrote: We’re all curious! On Jun 29, 2020, at 9:26 AM, Richard Gaskin via use-livecode wrote: On the use-livecode list you wrote: > Hey Alex, > > Public Domain it is. I’ve set it free couple. of years back, as I am > essentially no longer writing code. :-) Still following LiveCodes > progress with interest though. :-) > > Cheers, > > Malte If you're no coding, what are you up to these days? ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: OFFLIST Re: Animation Engine: speed tips
We’re all curious! > On Jun 29, 2020, at 9:26 AM, Richard Gaskin via use-livecode > wrote: > > On the use-livecode list you wrote: > > Hey Alex, > > > > Public Domain it is. I’ve set it free couple. of years back, as I am > > essentially no longer writing code. :-) Still following LiveCodes > > progress with interest though. :-) > > > > Cheers, > > > > Malte > > If you're no coding, what are you up to these days? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
OFFLIST Re: Animation Engine: speed tips
On the use-livecode list you wrote: > Hey Alex, > > Public Domain it is. I’ve set it free couple. of years back, as I am > essentially no longer writing code. :-) Still following LiveCodes > progress with interest though. :-) > > Cheers, > > Malte If you're no coding, what are you up to these days? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Animation Engine: speed tips
Thanks Malte. Hope you are enjoying whatever it is you're doing instead of writing code :-) Thanks again for having put AE into the Public Domain. Alex. On 29/06/2020 10:15, Malte Pfaff-Brill via use-livecode wrote: Hey Alex, Public Domain it is. I’ve set it free couple. of years back, as I am essentially no longer writing code. :-) Still following LiveCodes progress with interest though. :-) Cheers, Malte ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Animation Engine: speed tips
Hey Alex, Public Domain it is. I’ve set it free couple. of years back, as I am essentially no longer writing code. :-) Still following LiveCodes progress with interest though. :-) Cheers, Malte ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Animation Engine: speed tips
Hi there submariner :-), can you just confirm the licensing of AE ? The demo code says it is dual Commercial & GLPL3 - but GitHub says it is Public Domain. Can you just say which of those is correct ? Thanks Alex. On 28/06/2020 10:27, Malte Pfaff-Brill via use-livecode wrote: Hi, off it. might be worth digging into AEs source and change the handlers from using cProps to local variables. Also, there might be unnecessary instances. of locking / unlocking screen that. should be refactored in AE. If anyone is going to take that up I’d be happy iff you shared your patches to the community. :-) on All the. Best, Malte ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Animation Engine: speed tips
OK - will take a look. I suspect it is due to too many messages being sent due to the sort of line that is drawn when you create a curve by hand…. On 28 Jun 2020, 10:28 +0100, Malte Pfaff-Brill via use-livecode , wrote: > Hi, > > off > it. might be worth digging into AEs source and change the handlers from using > cProps to local variables. Also, there might be unnecessary instances. of > locking / unlocking screen that. should be refactored in AE. > If anyone is going to take that up I’d be happy iff you shared your patches > to the community. :-) > on > > All the. Best, > > Malte > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Animation Engine: speed tips
Hi, off it. might be worth digging into AEs source and change the handlers from using cProps to local variables. Also, there might be unnecessary instances. of locking / unlocking screen that. should be refactored in AE. If anyone is going to take that up I’d be happy iff you shared your patches to the community. :-) on All the. Best, Malte ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Animation Engine: speed tips
On 6/27/20 7:09 PM, David Bovill via use-livecode wrote: I made a quick test - creating and animating small graphic circles along a complex curve with many points. It works fine with one or two animated spheres but I’d like to be able to animate >30 and it slows to a crawl after 4 or 5. I tried setting the layer mode appropriately for all the objects - but I’m doing this on a new MacBook Pro - and it does not make a difference. Does anyone have an example stack with multiple animated objects that I can compare / test for speed? Hello David, You're welcome to play around with my sketchbook: https://speedbump.io/shared/yage-sketchbook.zip Ignore the first card, as it's my misunderstanding of how to effectively use Animation Engine, but the 2nd card uses the movePolygonal command to animate 60 objects across several polygons at about 60FPS on my Ryzen 3700X on Linux Mint 19.3. Frame rate jumps a tad on Windows, but I don't have a Mac to test with anymore. Would you be willing to share your stack? -- Derek Bump ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Animation Engine: speed tips
I made a quick test - creating and animating small graphic circles along a complex curve with many points. It works fine with one or two animated spheres but I’d like to be able to animate >30 and it slows to a crawl after 4 or 5. I tried setting the layer mode appropriately for all the objects - but I’m doing this on a new MacBook Pro - and it does not make a difference. Does anyone have an example stack with multiple animated objects that I can compare / test for speed? ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
