Animation, Image Format, Containers

[richmond62]

So: whether you like it or not, I have an obsession with achieving some sort of unclunky, unjuddery animations inwith OXT without using either:

on-the-spot image renderings using code, or animated GIF images (mainly because the control of these strikes me as tedious and not very good).

So . . . I am returning to my lolloping wolf . . .

-

Screenshot 2024-02-24 at 18.14.19.png (125.98 KiB) Viewed 363 times

-
And am going to "fool around" with both image formats and containers.

My original stack (viewtopic.php?p=6793#p6793) used PNG images in a graphic container.

Each 'wolf' PNG image weighed in at about 3 KB.

Each 'wolf' converted to a static GIF weighs in at about 1 KB.

The three "background" images weigh in like this:

"1.png" is 22 KB
"2.png" is 19 KB
"3.png" is 25 KB

This is slightly ridiculous as they were resized and locked AFTER they were imported into the stack.

Having done a bit of judicious pruning:

"2.png" is 14 KB
"3.png" is 30 KB ! (which is bonkers)

I shall now rebuild the stack with NO changes in the code, but using the static GIF images instead of the PNG images.
--

There is NO noticeable difference in the clunkiness of the animation.

Therefore the problem MAY lie in the coarse-grained nature of the movements.

[richmond62]

In both "SIDEWAYS.oxtstack" and "SIDEWAYS_2.oxtstack" the movements of the "wolf" and the background images is extremely coarse:
-

Screenshot 2024-02-24 at 18.41.19.png (239.38 KiB) Viewed 356 times

-
The "wolf" moving 56 pixels per animation frame.

By reducing the movements a slightly better effect is reached:
-

Screenshot 2024-02-24 at 18.52.46.png (229.46 KiB) Viewed 353 times

-
You should see that the code has been modified BOTH to provide a lap counter for the backGroundPatterns that is distinct from the movement counter, and the movement has been changed from 56 to 4 pixels per time.

The effect is STILL clunky, but less so.

[richmond62]

Bumping up the moveSpeed reduces the clunkiness:
-

Screenshot 2024-02-24 at 19.09.21.png (82.15 KiB) Viewed 350 times

-

[richmond62]

I think I'll just take a break to make one of my famous abusive remarks.
-

Screenshot 2024-02-24 at 20.58.21.png (67.31 KiB) Viewed 344 times

-
Just to really "rub things in", here's a snapshot from 'somewhere else':
-

Screenshot 2024-02-24 at 21.00.12.png (192.67 KiB) Viewed 343 times

[richmond62]

Using an image rather than a graphic as an animation container results in far less clunkiness:
-

Code: Select all

put image ("WR" & VULK & ".gif") into image "LOUP"

[tperry2x]

Yeah, the dictionary I had built upon has some issues reading the edited sqlite database.
If you put the original one in from the LC community version, it functions just fine.

I did mention this back here
https://www.openxtalk.org/forum/viewtop ... 6160#p6160

I assume there's something it doesn't like with the edited sqlite database, but not sure. With the original LC one, I had no issues - but that might be as to how this stack is referencing the database.

[richmond62]

I did mention this back here

Yeah: but that was at the full moon and I was more concerned with the hairs growing on the palms of my hands.
-

Screenshot 2024-02-24 at 21.24.57.png (232.73 KiB) Viewed 335 times

[richmond62]

Using set the location as opposed to move seems to make no obvious difference.

Code: Select all

 set the location of image "LOUP" to HORIZONTAL_POSITION_WOLF, VERTICAL_POSITION_WOLF

[tperry2x]

I think you've found the limits of OXT regarding smooth animation (or lack of).
If you have a look at the help menu > guides > Working with media section > "Working with Vector Graphics" - I've included the animation engine v6, so perhaps that would give you smoother results?

Although OXT & LC is fine at crunching a few numbers, and producing prototypes for a button interface, I don't see it ever being able to achieve something like this, this smoothly. We just have to have realistic expectations I suppose on what OXT / LC is capable of, and what it isn't.

[richmond62]

Not completely, as I have yet to get into move to the points here.

Of course that can be a pain-in-the-bum as it involves manipulating multi-point vector graphics as paths for whatever you are proposing to animate.

WATCH THIS SPACE.

[richmond62]

Well: pretty silly really: but it does illustrate how this works:
-

Screenshot 2024-02-24 at 22.22.40.png (121.8 KiB) Viewed 320 times

-
The button "GENERATE A PATH", oddly enough generates a 'random' path (i.e. a multi-point graphic) between some fairly strict constraints:

Code: Select all

on mouseUp
   put empty into fld "POYNTS"
   put 400 into UPDOWN
   put 10 into LRIGHT
   repeat until LRIGHT > 1390
      put LRIGHT/10 into LYNE
      put random(50) into VERT
      put random(2) into UD
      if UD = 2 then
         put (VERT + 390) into VERT
      else
         put (VERT + 340) into VERT
      end if
      put LRIGHT & "," & VERT into line LYNE of fld "POYNTS"
      add 10 to LRIGHT
   end repeat
   set the points of graphic "PATEKA" to field "POYNTS"
end mouseUp

Of course these points could go into a variable, an array, or a custom property: I put them into a scrolling list field so that people can see that something is going on.

The button "ANIMATE BLOB", err, animates the image "BLOB" by sending it along the path:

Code: Select all

on mouseUp
   move image "BLOB" to the points of graphic "PATEKA"
   wait 10 ticks
   set the location of image "BLOB" to 10, 400
end mouseUp

[richmond62]

It is perfectly possible to send an animated GIF along a multi-point graphic . . .

[tperry2x]

That moves and everything, but can you have that happening smoothly at the same time you have another object moving?

That's what animation engine does:
(demo of animating multiple objects without blocking)

Code is quite simple too:

Code: Select all

on mouseUp
   aeMoveTo the long ID grc "center", 200,200,1000,"overShoot"
   aeMoveTo the long ID grc 1 of grp "rotateMe",160,145,1000,"overShoot"
   aeMoveTo the long ID grc 2 of grp "rotateMe",150,250,1000,"overShoot"
   aeMoveTo the long ID grc 3 of grp "rotateMe",250,250,1000,"overShoot"
end mouseUp

[richmond62]

It is perfectly possible to send an animated GIF along a multi-point graphic . . .

This might go down in history as the worst bit of crap I have ever made
-

Screenshot 2024-02-24 at 22.41.44.png (58.85 KiB) Viewed 312 times

[richmond62]

A word of warning to the wise: do not touch those online animated GIF makers with a ten foot pole.

[richmond62]

Let's start our Sunday by mentioning a blasphemous word:

multithreading

Here are some canonical phrases:

without waiting

with messages

Were xTalk to have m*lt*thr**ding (censored), animations and so forth would be a much simpler affair.

https://forums.livecode.com/viewtopic.p ... ng#p222985

[OpenXTalkPaul]

I think you've found the limits of OXT regarding smooth animation (or lack of).
If you have a look at the help menu > guides > Working with media section > "Working with Vector Graphics" - I've included the animation engine v6, so perhaps that would give you smoother results?

Although OXT & LC is fine at crunching a few numbers, and producing prototypes for a button interface, I don't see it ever being able to achieve something like this, this smoothly. We just have to have realistic expectations I suppose on what OXT / LC is capable of, and what it isn't.

Oh yes, I'd forgotten Animation Engine was open source licensed a few years back, I've personally never used it, but I should take a look at it, perhaps we can include it and expand on it.

If you look at the side scrolling game demo here https://livecodeshare.runrev.com/stack/ ... -Game-Test
Which is an attempt to recreate a Super Mario Bros. Level, for the background it uses an image in a scrolling group and then sets the horizontal scroll of the group. It works well enough in LC CE 9.5.1, but for some reason it is significantly glitchy and slower in 9.6.3. Something effecting timing has changed between those two versions.

The other thing about that demo is that is polls the keysDown() instead of doing animation on KepUp pKey messages (which floods the message queue if your Key Repeat Rate is not set to 0 / off ) Polling and update rendering at regular on a timer intervals is the way to go.

[OpenXTalkPaul]

Your scripts can do other things while its moving an object on a path

move image "WOLFY" to the points of graphic "MyPath" in 6666 millisecs without waiting

Part of the problem here is syncing frames for an animated sequence, you can not just move the image box while it's changing frames of an animation without syncing to the movement of the animation, otherwise it will always look awkward.

When you made your wolfy animated GIF you must have set a long delay time set between the frames between.
The online GIF Makers that I've used have this set to a default of 20 which is too much for a sequence that only has 9 frames, it makes the run slow, so your move points must be further apart for it to look correct but then it looks unnatural, more like it's floating. You want it to be lower for this fast running sequence.

[OpenXTalkPaul]

This is why I've become interested in a making a library that can do things with the GIF data, things like change the time between individual frames without remaking the GIF in an external editor, and changing the color table would be cool too, then you can get animated effects like 'electrify' a sprite by changing the table. For example you could have a character get more red colored as their energy level gets low, just by changing the color table in the data and then setting the image data of the image control again. And most of all I want to be able to merge single frame GIFs to animated GIFs, and also split ani-GIF frames to individual GIFs.

https://en.wikipedia.org/wiki/GIF#Animated_GIF

[richmond62]

making a library that can do things with the GIF data

Sounds like a super idea,