"Street fighter Ken's synth" - Let's make Ken fly & kick

[tulamide]

Came back from a little vacation and found out those beautiful surprises here. Who needs more?

trog a true pioneer After a long weekend, I finally have some free time tonight, so I'll dig inside and as always, will try to understand what you did there. Thanks for that This is f...ing awesome!

Phill, I'm afraid tulamide's explanation says it all. But the envelope you've uploaded is winking me so I'm definitely going to try to cook something from it

tulamide, finally saw your dancing puppet. It's marvelous
I'm curious: how exactly you make it move like that? Are those body parts can be replaced by bitmaps?
I can, for example, take a cartoon character image, break it a part in photoshop and the you can replace these shapes with real body part images and give it a real cool looking. Moreover, you can use round robin style images switch and for instance, put different kind of facial expressions when the volume goes higher (or any other condition)

Welcome back

Re: Dancer it is more complicated than it looks. The key concept is inverse kinematics. I will spare you the wikipedia explanation that's correct but complicated. It basically means, if I move the left foot, every other body part automatically moves as well, according to skeleton and joint behaviours. So I don't need to animate every single bit, because math in the background does it for me. Instead I select hotspots and move only them. One example, in Dancer the audio is used to determine if the channels tend to the left or right side (calculating an average over a window size like half a second or something like that), and then the feet are moved accordingly. At the same time the pulsating (sorry, I don't find a better word) of the audio is measured and according to that the feet are moved up and down. Result: the dancer makes steps to the left or right and the other body parts follow automatically. And physics constantly calculate effects like gravity and apply them to the skeleton with IK taking care of correct behaviour of the bones and joints. You can see that in action if you have audio that plays (near) silence. Dancer will crouch then. But for the most part the physics calculations take care that Dancer always comes back to the ground (so that he jumps, instead of floating to the top, for example).

The body parts (bones) are simple 4p polygons with a texture (the camera is a fixed top-down view, so that it seems to be 2D). This texture can be anything. So yes, something like you described would be possible. But the IK and physics not. Also, it would be possible in Flowstone only when something like OpenGL, DirectX or WebGL are supported someday, since you need the graphics card to do all the graphic work, so that the CPU can concentrate on Physics and IK calculations. It really is tragic. Dancer comes with everything needed graphic-wise, and Flowstone with everything needed audio-wise (imagine reacting to different frequency bands for example). A mixture of both would be perfect.

And so I don't give up hope that some cool graphic card renderer will be supported someday by Flowstone

[kortezzzz]

Appreciate the detailed explanation, tulamide. That's a very interesting method and it's really sad that we can't use the graphics card for that. But why the current graphics method in FS doesn't match the needs of complicated fast animation tasks? It redraws OK, its fast enough to run sequential image sprites and move single shapes in fixed routines. Don't know about the CPU usage, but maybe you meant to that aspect?

[trogluddite]

The CPU load is the main problem, IMHO. For simple cases with only a few objects, it can be acceptable, but it doesn't scale up well at all, either in the number of animated objects, the frame rate, or the size of the view that has to be rendered for each frame.

A good example would be the textured polygons that tulamide mentioned. The texture bitmaps need to be scaled, rotated and de-aliased (and even more complex transformations if the view weren't "flat" top-down 2D). With FS as it is, that means that the main CPU would have to do a huge amount of calculations on big arrays of pixels for every single frame of animation, then blend those together with whatever else is in the view, then push a rendered graphics buffer to the graphics card.

With hardware accelerated rendering it would be enough to store the texture bitmap in GPU memory, then for each frame send a small command to say "draw it here to fit this shape", and the GPU does the rest of the work while your schematic gets on with something else. The GPU can do this work much more efficiently, too, because its hardware is designed around doing exactly that kind of number crunching.

Part of the reason that I ended up creating the 'outer-space/asteroids' schematic was to see how far I could reasonably push animating sprites while there was also other work and user-interaction going on. The CPU consumption rises rapidly as the module GUI is made bigger or the number of 'asteroids' is increased. All of the (only 2D!) movements are Ruby doing mathematical transformations on arrays of (x, y) points, and the CPU then has to calculate all of the bezier curves that join the points, and then how to fill them all with colour - for every single new frame (and the frame-rate is conservatively limited, too!)

What's considered "reasonable" CPU load, and what compromises are "reasonable" to keep it in check, are subjective, of course - a trade-off to be made for each situation where we need or want animation. But for FS as it is, the upper-bound where things start getting glitchy will always be much lower than for hardware-accelerated rendering.

[kortezzzz]

I see. So it seems that flowstone is made to work under a reasonable amount of graphic elements like knobs and buttons. Anything esle was taken into acount. But it makes sense if we remember that FS/synthmaker developed in the early 2000 ( and nothing really critical changed since then).

However, there is still hope

[wlangfor@uoguelph.ca]

mmk *downloads street fighter synth.

Thanks