Flipping Cards

[OpenXTalkPaul]

This is the method Paul talked about, using the lcb extension. You'll have to load that in via the "Tools" menu > "Extensions Manager", then open the oxtstack.

Widget from here.

That's the one from Hermann Hoch that inspired me to do my own experiments with that in Extension Builder.
And this one too: https://hh.on-rev.com/widgets/turnimage.html

They work fine with the Community Engine, but unlike most of his work (that were MIT licensed), HH did NOT include the source for those two widgets (so we can't include them with the IDE). So what I did was to experiment with that Builder-wrapped Skia image transform function myself, making the parameters into properties that are accessible from the Property Inspector.

Here's some documents about the mathematics of warping pixel images:
https://academicworks.cuny.edu/cgi/view ... xt=ho_pubs
https://quadst.rip/warp
https://people.computing.clemson.edu/~d ... -warps.pdf

To be honest, when I see math, like in some of those above links, my brain starts to ache,
Fortunately the Engine already includes libSkia which already has the needed transform functions enough to do a 2D to 3d-card flip (as seen in HH's work). If you want other sorts of distortions (like curved distortions) you'd have to work it out yourself and do the operations directly to the pixel image data.

[tperry2x]

I've been doing some tweening.
Clunky and chunky: BUT the blasted thing works . . .
Mind you, the thought of making all those images for 22 Tarot cards, or 52 playing cards, makes me feel a bit woozy.

Here's my clunky thing too.
I haven't gone too far with it, as it's rough - but you can see what I was thinking.

rough-flipping.gif (159.21 KiB) Viewed 1296 times

Essentially, divide the card image up into segments via script, then pull at each segment to give the illusion of it turning. Needs a lot of refinement, just an idea at present.

[OpenXTalkPaul]

Essentially, divide the card image up into segments via script, then pull at each segment to give the illusion of it turning. Needs a lot of refinement, just an idea at present.

That sounds like a pretty clever method (can't look at the script at the moment), and it looks pretty good too (as a GIF).

That reminds me, the engine had support for '9-Slice' images added to it at one point, and I never got around to trying that out.

You would only need a single common set of frames for the card-back, so that could be already cached and ready to go for the 'back' half of the animation.

[richmond62]

My stack used a series of images made using the 3D Transform thing in GIMP:
-

Screenshot 2024-12-31 at 11.59.21.png (222.82 KiB) Viewed 1255 times

-
As GIMP is Open Source I wonder if . . .

AND, having just discovered this, GIMP goes up in my estimation like nobody's business!

https://www.gimp.org/

[richmond62]

Screenshot 2024-12-31 at 14.33.15.jpg (202.64 KiB) Viewed 1241 times

-
Attached stack removed as a new version has been appended to the next posting.

[richmond62]

Here's a question that strikes me as a bit queer from across the way:

Was 19 enough resolution to make the action smooth? My gadget had 80 discrete steps in each direction, which was the minimum I felt in order to look OK.

19 images DOES make the animation look smooth.

I am now going to make a version with fewer images to see what I can get away with.

Using ONLY 10 images does NOT produce any obvious degradation over 19.
-

Screenshot 2024-12-31 at 20.08.12.png (263.08 KiB) Viewed 1224 times

[OpenXTalkPaul]

19 images DOES make the animation look smooth.

I am now going to make a version with fewer images to see what I can get away with.

Using ONLY 10 images does NOT produce any obvious degradation over 19.
-
Screenshot 2024-12-31 at 20.08.12.png

How many frames you need to look smooth enough (arbitrary) depends a lot on how much time your want your animation to consume. I always tried to used about 24 frames per-second (PAL video) or 30 fps (NTSC video) but I've also used half that (12/15 fps) to try to keep to smaller file sizes. So to do 30 fps you need to render 1 image every 1/30th of a second, that's about 33.3 milliseconds. That can be a bit of a strain for our 34+ year old interpreted scripting engine., specially if the images are on the larger size or are higher-resolution.