Page 1 of 2
A cactus in the backside
Posted: Sun Jul 18, 2021 11:24 am
by richmond62
-
So, I have a "silly little animation"
(images thanks to the good folks at
https://craftpix.net/
Download link removed as improved version available further down.
with 2 buttons called "WL" and "WR" respectively to animate my 'boy' across the screen
with this sort of code:
Code: Select all
on mouseUp
put item 1 of the loc of grc "ramka" into LR
put item 2 of the loc of grc "ramka" into UD
repeat until LR < (- 50)
put 1 into WALKL
repeat until WALKL > 6
set the width of grc "ramka" to the width of img ("L" & WALKL & ".png")
set the height of grc "ramka" to the height of img ("L" & WALKL & ".png")
set the backGroundPattern of grc "ramka" to the ID of img ("L" & WALKL & ".png")
add 1 to WALKL
subtract 10 from LR
move grc "ramka" to LR, UD
wait 20 ticks
end repeat
subtract 10 from LR
move grc "ramka" to LR, UD
end repeat
end mouseUp
AND the blasted thing seems to
flash in an extremely annoying way at the end of each inner repeat.
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 2:29 pm
by stam
richmond62 wrote: ↑Sun Jul 18, 2021 11:24 am
AND the blasted thing seems to
flash in an extremely annoying way at the end of each inner repeat.
Hi Richmond,
i'm not getting any flashes, but animation is jerky - seems to be a bit smoother if reducing the 'wait' to 10 ticks, but then i don't know much about animating sprites etc. On occasion on opening the stack i get the whole background showing as black.
Would using animationEngine help make this smoother?
Stam
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 2:31 pm
by dunbarx
How did I Know, just reading the title, that Richmond was behind all this?
Would locking the screen at the beginning of the repeat loop and unlocking at its end help?
Craig
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 3:20 pm
by richmond62
Would locking the screen at the beginning of the repeat loop and unlocking at its end help?
Brilliant: no one would see the animation: but then they wouldn't see any flickers either.
Would using animationEngine help make this smoother?
Probably after I have told all my summer kids to shell out the money for it.
How did I Know, just reading the title, that Richmond was behind all this?
A really simple way to separate those who 'do' from those who 'don't' without those who 'don't' opening the post
in the first place.
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 3:31 pm
by richmond62
The "main problem" is that there are effectively 2 types of animation going on:
1. The sequence of images used as backGroundPatterns for a round rectangle graphic.
2. The movement of the round rectangle graphic across the stack.
I always have a feeling that a programming language should be capable of doing everything without add-ons.
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 5:18 pm
by dunbarx
Richmond.
I did say to unlock the screen each iteration, you know.
Craig
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 5:44 pm
by richmond62
I apologise:
Code: Select all
on mouseUp
put item 1 of the loc of grc "ramka" into LR
put item 2 of the loc of grc "ramka" into UD
repeat until LR < (- 50)
put 1 into WALKL
repeat until WALKL > 6
set the lockScreen to true -- dunbar
set the width of grc "ramka" to the width of img ("L" & WALKL & ".png")
set the height of grc "ramka" to the height of img ("L" & WALKL & ".png")
set the backGroundPattern of grc "ramka" to the ID of img ("L" & WALKL & ".png")
add 1 to WALKL
subtract 10 from LR
move grc "ramka" to LR, UD
wait 20 ticks
set the lockScreen to false -- dunbar
end repeat
subtract 10 from LR
move grc "ramka" to LR, UD
end repeat
end mouseUp
results in no flashing at all.
Can you explain why?
As you have pointed out, the animation is jerky: but by reducing the
size of the lateral movement of the graphic
and the
wait period that can be overcome.
Improved version here:
https://www.dropbox.com/s/kbpa0dhcc1mvw ... e.zip?dl=0
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 5:50 pm
by richmond62
animationEngine
With all respects to Malte Brill I have never had the chance to look at his work.
While it is dual-licensed:
viewtopic.php?t=22361
I am using animation to teach children LiveCode and want to keep things 'pure'.
But I have been animating stuff like the way demonstrated above for about 7 years and
have never encountered that flashing before.
I wondered if it was an optical effect caused by:
1. My ageing eyes.
2. Too much beer at lunchtime.
3. Forgot to chant my morning mantras [err . . . strike that one].
But having had a pair of 10 year olds look at things they also saw some flashing going on.
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 5:52 pm
by mwieder
[NOTE:] I typed this in before your latest, but here it is anyway.
I don't see screen flashing here. But the movement is indeed pretty jerky due to a couple of things.
First of all, as Craig suggested, locking and unlocking the screen inside the inner repeat loop allows the graphic mangling to take place out of camera range. Secondly, as Stam suggested, the wait statement seems unnecessarily long. Cutting down the wait time helps with this, but I get the best effect by removing the wait completely.
Here's a fairly smooth animation effect without flashing or jerkiness.
Code: Select all
on mouseUp
local LR, UD, WALKL
put item 1 of the loc of grc "ramka" into LR
put item 2 of the loc of grc "ramka" into UD
repeat until LR < (- 50)
put 1 into WALKL
repeat until WALKL > 6
lock screen # do this out of sight
set the width of grc "ramka" to the width of img ("L" & WALKL & ".png")
set the height of grc "ramka" to the height of img ("L" & WALKL & ".png")
set the backGroundPattern of grc "ramka" to the ID of img ("L" & WALKL & ".png")
add 1 to WALKL
subtract 10 from LR
move grc "ramka" to LR, UD
unlock screen # now show what's been done
--wait 20 ticks # no
end repeat
subtract 10 from LR
move grc "ramka" to LR, UD
end repeat
end mouseUp
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 7:05 pm
by jacque
If speed control is desired, why not use:
Code: Select all
move grc "ramka" to LR, UD in 10 ticks without waiting
I confess I didn't actually test this.
EDIT: I did just test this and it doesn't work. So there's that.
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 7:17 pm
by SparkOut
It appears you already have answers to address some of these issues.
One thing I found in animation a few versions ago (not really done anything of the ilk in recent times) which therefore may not be worth mentioning: when moving an object (button/sprite/icon/whatever) the rendering of the "leading edge" seemed to be problematic, with the "original" edge being the "mask" but the "after movement" position being the "trailing edge" so it looks like the front of the object is cut off.
This was remedied by having a little buffer area of transparency around the object, so that only the transparent part gets cut off znd hence not noticeable. It might be a bit relevant, or not.
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 7:28 pm
by richmond62
a little buffer area of transparency around the object
Is that round the images in the sequences used as backGroundPatterns in the graphic or
re the borders of the graphic compared with those images?
The problem is that if one expands the size of the graphic one gets the images repeating (tiling).
-
-
I suppose one could go back and expand the transparent area round each image
(although, when I think about that, I suddenly remember that I have to go and have a bath
so I don't smell like a rank raccoon tomorrow in class - 36 degrees Celsius with 75% humidity
here today) in the sequence.
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 8:15 pm
by SparkOut
richmond62 wrote: ↑Sun Jul 18, 2021 7:28 pm
I suppose one could go back and expand the transparent area round each image
Yes, this - but the target area would be sized to match. No tiling necessary. Bath, probably.
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 10:17 pm
by stam
More for my own interest and as a diversion i played a bit with this - i dislike things running in loops as they can lock the interface.
For example it can be hard to change directions or pause.
An alternative is to recursively call an animation/movement with 'send to me in xx ticks' which doesn't block the interface. By and large i got this to work just fine but very weirdly the sprite slowly wanders upwards in the screen! Not sure why... even if i try to fix it to a line, it still wonders up...
this is the code in the card script:
Code: Select all
global gStop
local sPhase, sLoc, sDirection
command marchSprite pDirection
local tDir, tStep, tRect, temp
put pDirection into sDirection
if sDirection = "left" then //images named L1-6 and R1-6
put "L" into tDir
else
put "R" into tDir
end if
//sPhase 1->6
add 1 to sPhase
if sPhase > 6 then put 1 into sPhase
lock screen
set the height of graphic "animationRect" to the height of image (tDir & sPhase & ".png")
set the width of graphic "animationRect" to the width of image (tDir & sPhase & ".png")
set the backgroundPattern of graphic "animationRect" to the id of img (tDir & sPhase & ".png")
unlock screen
if not gStop then
put the rect of graphic "animationRect" into tRect
if sDirection = "left" then
if the left of graphic "animationRect" > 20 then
lock screen
add (-1 * field "step") to item 1 of tRect
add (-1 * field "step") to item 3 of tRect
set the rect of graphic "animationRect" of me to tRect
set the botton of graphic "animationRect" of me to the top of graphic "line" //attempt to stop hovering upwards!
unlock screen
else
exit to top
end if
else
put item 3 of the rect of this stack - the width of graphic "animationRect" * 3 into temp
if item 3 of tRect <= temp then
lock screen
add (field "step") to item 1 of tRect
add (field "step") to item 3 of tRect
set the rect of graphic "animationRect" of me to tRect
set the botton of graphic "animationRect" of me to the top of graphic "line"//attempt to stop hovering upwards!
unlock screen
else
exit to top
end if
end if
else
exit to top
end if
send "marchSprite pDirection" to me in field "ticks" ticks
end marchSprite
on escapeKey
put true into gStop //makes animation stop
exit to top
end escapeKey
Any idea why it the sprite wanders up the screen?
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 11:49 pm
by bn
Hi Stam,
I think the upward movement stems from the images being 100 and 101 in height so the loc of graphic "animationrect" changes.
The correction does not work because of a typo: botton instead of bottom
Code: Select all
set the botton of graphic "animationRect" of me
When fixing the typo the animation stays on the horizontal line
Kind regards
Bernd