There were many study materials that were made in Flash that came back alive with the help of Ruffle. Here's my fav list: https://astro.unl.edu/animationsLinks.html
Building a new Flash
161–170 of 247 posts
Re: Building a new Flash
#162For someone like me who never got the opportunity to play with Flash, what are some modern equivalents? Is it Rive or Three.js? Or even Godot Web?
Rive is closest sonce they have scripring support. Threejs is a 3D graphic libary, something different. And godot web I never used but know of as a game engine, not a scriptable animation tool.
As Godot is still very simple from the UX perspective, I'd prefer a set of tools to fully replicate the flash workflow instead of a dedicated app. Why reinvent the wheel? Stuff like keyframe animation editor etc is already there anyway and the engine is powerful enough. Just missing some tools, which could be easily added via the asset store.
Re: Building a new Flash
#163I never developed with Flash but my understanding is that "modern web" can do everything Flash was used for. So my understanding is that most useful thing is probably the .fla importer. Wouldn't it make sense to focus on authoring-tooling (animator+developer coop) and the importer but "export" to standard web tech?
Re: Building a new Flash
#164Earlier quoted context omitted.
AFAIK the .fla format was never fully documented or reverse engineered by anyone (FFDEC has an exporter, but not importer), so this alone would be a bold claim.
https://ruffle.rs/ is pretty solid
I'm talking about the .fla (XFL) format, not .swf (which is documented well - though that doesn't mean its exact behavior its understood well)
(note: I'm one of Ruffle's maintainers)
Re: Building a new Flash
#165Marc Canter (founder of MacroMind/MacroMedia) one explained to me something revealing about the Director timeline (their original product before Flash, later integrated with the web browser as Shockwave):
It's essentially just a BASIC program rotated 90 degrees on its side, full of GOTOs.
https://news.ycombinator.com/item?id=35652164
DonHopkins on April 21, 2023 | parent | context | favorite | on: Show HN: Thoughts on Flash in 2023, in Flash, in 2...
I love all the amazing inspirational open source examples of generative procedural art and artificial life that Jared Tarbell published on his web site https://web.archive.org/web/20070202025610/http://levitated.... .
It opened my eyes to using Flash for procedural graphics and simulations, instead of just using timelines like a glorified graphical player piano, or like a BASIC program full of GOTO spaghetti rotated 90 degrees counter clockwise (which is how Macromedia founder Marc Canter described Director's Lingo, which also used frame numbers like BASIC line numbers).
Jared went on to do a lot more amazing stuff in Processing, co-founded Etsy, and built a toy factory!
https://www.artnome.com/news/2020/8/24/interview-with-genera...
https://www.artnome.com/news/2018/8/8/why-love-generative-ar...
https://beyondtellerrand.com/events/dusseldorf-2018/speakers...
Re: Building a new Flash
#166This is exactly the Ardour model (and what Aseprite did before their license change). It's a highly viable way to sustain a niche FOSS desktop app in 2026. Make the repo open source, but put a price tag on the official, signed binaries on the main website. The professionals who need this to get work done will gladly pay a fee to avoid spending an afternoon fighting with Avalonia dependencies and build environments. T…
Isn't it dangerous to give up all the code of a commercial software in the age of LLM? Competition can clone the project in another language and lipstick it to look different.
I suspect this overestimates the value of raw code. Anyone can use an LLM to reskin a project but they can't use it to replicate the trust that's built over time. The moment someone forks the code, they inherit a massive maintenance burden. They have to manually verify every change or risk shipping broken garbage. Most professionals will gladly pay a premium for a signed binary from a trusted maintainer rather than risk their workflow on a cut rate clone.
The real moat is not the source itself but the reputation. Setting the right price point is the actual challenge. You have to find that sweet spot where the price is high enough to fund development but low enough that the friction of paying is less than the friction of cloning the repo and building it yourself. If you price it like a corporate seat then people will fork it out of spite. The goal is to make the official binary the path of least resistance.
Re: Building a new Flash
#167I made Flash Games back in the day. Here's my old profile on Newgrounds: https://cableshaft.newgrounds.com/ One thing Flash had that nothing else has really seemed to replicate as well since, is an environment that both coders and artists could use. I'd collaborate with an artist, they'd make their animations within an FLA, send it to me, and then I'd copy+paste into the project file, and it'd just work. I could even…
Flash was great. Is there anything Flash could produce that wouldn't render these days with SVG + CSS + JS? I remember trying to produce a Flash renderer in C# when we wrote DudeFactory to render out the characters after you used the Flash app to put all their clothes and accessories on. I think we cheated in the end and pre-rendered large PNGs of them all and used .NET to just layer them all with instructions sent f…
Technically you may not even need js, since SVG has integral support for SMIL.
Re: Building a new Flash
#168Earlier quoted context omitted.
AFAIK the .fla format was never fully documented or reverse engineered by anyone (FFDEC has an exporter, but not importer), so this alone would be a bold claim.
https://ruffle.rs/ is pretty solid
ruffle is a player for the output format (swf), .fla is the authoring format
Re: Building a new Flash
#169Earlier quoted context omitted.
There would still be the security issues, but yea this is still true
Sure, maybe, but I think if it were FOSS'd back in ~2005, then these security issues could be addressed by a larger set of eyes, including the browser-makers themselves. If this hypothetical universe happened, I think we'd have had something akin to WASM much earlier. Flash already had its own bytecode and VM, and even had something roughly like Emscripten [1] to compile existing C++ code to Flash. [1] https://en.wik…
ESR's "many eyes" quote in his "Linus's Law" is unmitigated bullshit. And Linux Torvalds should not be blamed for it, since it wasn't his law, ESR just named it after him to get attention. Hardly anyone actually reads code, and the few people actually qualified to find bugs by reading huge piles of buggy code dumped into the public domain when a company abandons it have much more important things to do with their time.
If the many eyes that Macromedia and Adobe paid to work full time on Flash couldn't prevent the need to push out Flash security patches several times a week, the code is fundamentally flawed far beyond the point that the few much less qualified people who might actually take their unpaid spare time to look at it are able to finally find and fix all the bugs.
The major browser developers have enough on their hands designing new open standards and writing and debugging new code, without having to spend any of their time burning their eyes and brains looking at free abandoned obsolete toxic waste code dumps. And ESR certainly isn't going to chip in and help them.
https://news.ycombinator.com/item?id=43133598
>He made up the ridiculous "many eyes" quote himself, then misnamed it "Linus's Law" to avoid personal responsibility and shift the blame to innocent Linus Torvalds, who never said such a stupid thing, and which HeartBleed and many other eyeballable bugs proved terribly wrong and misguided.
>About which the salty security expert Theo de Raadt famously said "Oh right, let's hear some of that "many eyes" crap again. My favorite part of the "many eyes" argument is how few bugs were found by the two eyes of Eric (the originator of the statement). All the many eyes are apparently attached to a lot of hands that type lots of words about many eyes, and never actually audit code."
https://en.wikipedia.org/wiki/Linus%27s_law
>In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate.[4] While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".[5]
>The persistence of the Heartbleed security bug in a critical piece of code for two years has been considered a refutation of Raymond's dictum.[6][7][8][9] Larry Seltzer suspects that the availability of source code may cause some developers and researchers to perform less extensive tests than they would with closed source software, making it easier for bugs to remain.[9] In 2015, the Linux Foundation's executive director Jim Zemlin argued that the complexity of modern software has increased to such levels that specific resource allocation is desirable to improve its security. Regarding some of 2014's largest global open source software vulnerabilities, he says, "In these cases, the eyeballs weren't really looking".[8] Large scale experiments or peer-reviewed surveys to test how well the mantra holds in practice have not been performed.[10]
>Empirical support of the validity of Linus's law[11] was obtained by comparing popular and unpopular projects of the same organization. Popular projects are projects with the top 5% of GitHub stars (7,481 stars or more). Bug identification was measured using the corrective commit probability, the ratio of commits determined to be related to fixing bugs. The analysis showed that popular projects had a higher ratio of bug fixes (e.g., Google's popular projects had a 27% higher bug fix rate than Google's less popular projects). Since it is unlikely that Google lowered its code quality standards in more popular projects, this is an indication of increased bug detection efficiency in popular projects.
Re: Building a new Flash
#170Haxe used to be the goto for Flash development. Maybe it could benefit a project like this too. I assume the target is AS5?