To be clear, I didn't (exactly) mean that the author of a Flash animation has to think in terms of creating a "demoscene demo." I rather meant that the Flash abstract machine is designed to primarily do the types of thing that demoscene demos do — i.e. to use vectors and gradient fills and clipping masks to achieve procedural visual effects. You could say that the SWF abstract machine has a "demoscene-alike Instruction Set Architecture." Most of the work of figuring out how to achieve particular visual effects on that abstract machine, though, is domain-knowledge built into the "Flash compiler" of the authoring tool.
In my previous post, I emphasized Flash as a distribution format for a reason. While the authoring tools (and the .FLA project format) do work with clean abstractions of a timeline with keyframes and tweens (and objects with their own swappable animations that have their own sub-timelines), the .SWF export format bakes all that down into an imperative program for an abstract machine whose primitive opcodes involve defining and moving around (potentially texture-filled) vector objects on a canvas. Writing SWF bytecode directly, would be similar to programming against a retained-mode fixed-function graphics API like OpenGL — just without any 3D support. In other words, it would be like writing a demoscene demo.
Or, to put that another way: the core of the .SWF export format — before all the user programmability stuff was added — is basically a cousin of PostScript, but with a finishRenderAndWaitForNextFrame command, and the ability to set spline points' velocities. Which is very much unlike declarative vector formats like SVG. The closest comparison, I think, might be to the object-oriented vector display-lists used in vector-based arcade machines (see e.g. https://www.youtube.com/watch?v=smStEPSRKBs.)
But, in both the arcade games I mentioned, and in Flash, if you've achieved the effect you want and are now optimizing the final work for size and performance, doing so will mostly be a matter of modularity and reuse of small repeatable design elements. Having "mechanical sympathy" for what the Flash export format looks like, will push you toward certain authoring decisions, e.g. building complex scenes using many smaller primitive objects that each independently animate (or in later versions of Flash, are independent state-machines); creating objects that can be uniform and so constructed by cloning rather than redefinition (leading to a surprising number of 2D flash animations and later games that were built out of colored, untextured voxel boxes); etc. And — despite there being no actual programming involved in the Flash animation authoring case — this is still very much akin to the process of optimizing a demoscene demo.
> While the authoring tools (and the .FLA project format) do work with clean abstractions of a timeline with keyframes and tweens (and objects with their own swappable animations that have their own sub-timelines), the .SWF export format bakes all that down into an imperative program for an abstract machine whose primitive opcodes involve defining and moving around
I mean, you can describe SWF like that, but it's not really what people think now when you say that it's an abstract machine. The SWF file is indeed a series of commands like: "put this object in this layer, and assign this matrix to it".
However, SWF still preserves the notion of persistent vector objects (called "characters") down to the display level. You're not just preparing a command list and then submitting it to a GPU for rendering (like with OpenGL), and then re-doing it again for the next frame.
Characters in SWF are persistent. Flash does all the composing, clipping, and it even does automatic interpolation for you for morphing.
SWF format is now open: https://open-flash.github.io/mirrors/swf-spec-19.pdf - the page 35 contains the description of the most important instruction "PlaceObject" that was used to actually do the animations.
In my previous post, I emphasized Flash as a distribution format for a reason. While the authoring tools (and the .FLA project format) do work with clean abstractions of a timeline with keyframes and tweens (and objects with their own swappable animations that have their own sub-timelines), the .SWF export format bakes all that down into an imperative program for an abstract machine whose primitive opcodes involve defining and moving around (potentially texture-filled) vector objects on a canvas. Writing SWF bytecode directly, would be similar to programming against a retained-mode fixed-function graphics API like OpenGL — just without any 3D support. In other words, it would be like writing a demoscene demo.
Or, to put that another way: the core of the .SWF export format — before all the user programmability stuff was added — is basically a cousin of PostScript, but with a finishRenderAndWaitForNextFrame command, and the ability to set spline points' velocities. Which is very much unlike declarative vector formats like SVG. The closest comparison, I think, might be to the object-oriented vector display-lists used in vector-based arcade machines (see e.g. https://www.youtube.com/watch?v=smStEPSRKBs.)
But, in both the arcade games I mentioned, and in Flash, if you've achieved the effect you want and are now optimizing the final work for size and performance, doing so will mostly be a matter of modularity and reuse of small repeatable design elements. Having "mechanical sympathy" for what the Flash export format looks like, will push you toward certain authoring decisions, e.g. building complex scenes using many smaller primitive objects that each independently animate (or in later versions of Flash, are independent state-machines); creating objects that can be uniform and so constructed by cloning rather than redefinition (leading to a surprising number of 2D flash animations and later games that were built out of colored, untextured voxel boxes); etc. And — despite there being no actual programming involved in the Flash animation authoring case — this is still very much akin to the process of optimizing a demoscene demo.