Hey HN, I haven't done a lot of technical postmortem blogpost-style writing
so I'd welcome any feedback or tips on how to improve. Is it too long, too
short, too technical, not technical enough? Boring? Interesting? Is it
enlightening or does it just come off like content marketing? I literally
have no idea how good I am at this.
I don't think anyone here is going to complain about a post where you make a game work by reverse engineering Bezier splines encoded in XML by Adobe Flash.
However I wonder why the OP didn't try to keep vector graphics and use to SVG for instance? That would allow for infinite scalability. It is mentioned that "GPUs don't like vectors" but if the game doesn't change too often it should not make a lot of difference?
I did consider it. Infinite scalability isn't required during runtime; the scene doesn't ever zoom or scale in the games, because that was always so slow in Flash, so the only real benefits would be 1) supporting higher resolutions and 2) reducing file size.
For 1) I decided I'd rather just release an update with larger textures if these ones ever start to look dated. That way I get to keep the runtime code simple. Less code means fewer bugs. I don't want to spend a lot of time fielding support requests from users who hit edge cases in the rasterizer. As for not changing too often, that's true, but taking advantage of that means doing change tracking with dirty-rectangles or similar, which not only adds complexity but also feels like it would make performance less predictable.
And for 2) the game as it stands now is under 50MB so I didn't feel a pressing need to make it smaller, although a tiny executable would be cool in a satisfying, demoscene kind of way.
So, I think I need to elaborate on "GPUs don't like vectors". What the OP meant was "GPUs have literally no support for rendering anything other than pixels on triangles and getting them to efficiently draw Bezier curves and fills is an active area of research". You'd need specific hardware support for rasterizing them, and as far as I'm aware no such hardware exists.
When Adobe hacked on "HTML5 support" to Animate, they did exactly the same thing the OP did. It renders every shape in the FLA to a sprite sheet and then draws it to a canvas tag. If you have knowledge over what will be drawn ahead of time, this is the most reasonable thing you can do.
Even before HTML5 support, the AS3 Starling framework that let you "use the GPU" would pre-render all your vector assets to bitmap textures at runtime. And that was a framework built for Flex developers; if you were accustomed to building things on the timeline, you rendered on CPU, because that's where all of Flash's very particular rendering logic has to live.
Ruffle gets around this by tesselating every shape into a GPU-friendly triangle mesh. This lets us render stuff that's technically vectors on GPU. But as you can imagine, this creates its own problems:
- Flash has very specific stroke-scaling rules. If a stroke is smaller than 1px[0], it will be rounded up to 1px. This is how Flash's "hairline stroke" feature works: it actually asks for a 1/20px[1] stroke, and that gets rounded up to whatever the current scaling factor for that shape is. When your stroke is a polygon mesh, you can't vary the stroke to match Flash without retesselating, so hairline strokes on shapes that stretch don't animate correctly.
- Likewise, any stretch of a stroke that changes the aspect ratio also distorts the stroke, since its baked into the tesselated mesh. There's a minigolf game that does this to hairlines and it will basically never look right in Ruffle.
- Tesselated vectors lose their smoothness, so we have to sort of guess what scale the art is drawn at and add enough detail polygons for things to render correctly. Most of the time we get it right. However, there are some movies that do crazy things like store all the art at microscopic scale and blow it up. This provides a compression benefit, because it quantizes the points on the art with little visual difference on Flash Player. On Ruffle, however, the art becomes very low-poly.
- All the tesselation work takes a significant amount of time. There are certain movies (notably, a lot of Homestuck) that would hang the browser because of how much ridiculously complicated vector art was being processed before the movie even loads. We had to actually limit how much art could tesselate per frame, and expose that to movies as bytesLoaded, which is why Ruffle movies have preloaders even though we don't support streaming download.
There's another approach to drawing Beziers on GPU: drawing the hull of control points with a procedural texture that calculates the underlying polynomial. This is especially simple for quadratic curves (the ones with one control point), which is what all Flash timeline art[2] is.
However, strokes are more complicated. You'd think we could just take the hull of the stroke and draw that as a fill, but you can't. This is because the offset of a Bezier curve is not a Bezier curve. Drawing the stroke in a pixel shader would make sense, except you still need to define a polygon mesh around your stroke with a reasonable texture coordinate system to make the math work. And the polygonal outlines of Bezier curves can get really funky; there's no obvious way to quickly say "here's a curve, now give me the polygon that encloses a 5px stroke around it". Remember how tesselation takes so long that it would hang Ruffle?
[0] I'm not sure if this is virtual or device pixels.
[1] Flash specifies vectors in fixed-point units called twips. That's why the zoom factor on Flash movies was locked to 2000%.
[2] Flash can draw cubics - the two-control-point curves you think of when you think Bezier - but only in response to an AS3 graphics command. We haven't implemented this in Ruffle yet.
> "GPUs have literally no support for rendering anything other than pixels on triangles and getting them to efficiently draw Bezier curves and fills is an active area of research"
Well fuck me, I had no idea. I figured that 'simple 2D vectors' would be beyond piss-easy for modern GPUs. I'd never considered that it wasn't the actual math space that was accelerated, rather the fast memory mapping of everything on presumably comparatively simple geometries. You've just turned my view of the world upside down :(
Yeah, this is something that many many people assume (vectors are "easy" on GPUs) and then are amazed (like I was!) that they aren't even in the function set. My thought was that if you were "accelerating" desktops you'd really want vectors right? But no.
The interesting thing is that graphics cards in the 90s - which were "desktop accelerators" past the low end - specifically supported accelerated 2D primitives, including Bezier curves for the more powerful ones. It was all gradually dropped as cards focused on 3D games specifically.
Have you tried splitting the area covered by each shape into several 8x8 pixel rectangles, then running a compute shader over each one that executes the exact same rasterisation algorithm as Flash did? That's more or less how triangles are rasterised on the GPU anyway.
It's definitely not a simple solution, but might enable you to do runtime rasterisation with a good framerate on the GPU rather than pre-rasterising all the vector art.
Also, as far as I understood, both GNU Gnash and Lightspark were using OpenGL for rendering. So I always expected that GPU would still bring some sort of acceleration for 2D path rendering ?
Flash was my 2nd programming language (after VB6) back when it was still Macromedia. I had a lot of fun making really crappy minigames and learning the basics of coding. This article brought some good nostalgia and plenty of astonishment at the lengths you went to.
Your writing itself is great. A lot of writing linked by HN seems too verbose because people try to sound smart. Yours is succinct while engaging. Right length, just technical enough, and interesting. I really enjoyed this, thanks for writing it!
Also:
> Object-orientation is not fashionable right now in gamedev circles
Object-orientation is kind of the old-school way of doing things, these days it's all about ECS - entity component system. This is a more data-oriented approach that has the potential for much higher performance when you have thousands of objects that need updating in your game. It's similar to how OO languages like Java/C# are going out of style and more (nominally, at least) data-oriented languages such as Go or Rust are in style.
I watched this talk years ago: CppCon 2014: Mike Acton "Data-Oriented Design and C++"
I was very impressed by the ideas presented.
Java/C# can be used to write a program with "just a bunch of structs + static methods". Isn't that data-oriented enough? Ya, I know we can do 72 levels of inheritance also... for ignore that for a moment.
Yeah, "OO is going out of fashion" is a common phrase in gamedev, but what's actually meant is "deep class hierarchies defining the behaviour of game objects is going out of fashion". Most ECS code is still written in OO languages and makes heavy use of OO features.
Probably how OO teachers and mentors failed horribly (AFAIK we still don't warn new students about the pitfalls of inheritance ?), so ECS got popular as a better alternative to shitty OOP code ?
Not only that, but due to CPU caches and memory alignment issues, ECS have better performance than inheritance; also because most ECS systems ditch virtual function calls.
Whether or not an ECS will actually be faster depends entirely on the type of game and access patterns of the inheritance structure. Further, it matters how you are doing inheritance (LTO can eliminate a lot of the pitfalls even if you use virtual function calls).
This is nothing against ECS. I just find the current claims of performance dubious and potentially flat out wrong given modern compiler optimizations and changes in CPU caches (mainly that they got a LOT bigger).
I believe claims of "compilers getting faster/bigger enough" are the exact reason we have ECS now. It surely depends of the kind of game, but games with any kind of entity which isn't unique should feel the performance improvements.
Ideally, compilers should be able to transform classes into ECS layout when generating code. Shouldn't be hard to have a pass before compilation, if we use clang.
There's a gem of a hidden narrative here for more junior developers that you don't always need to start over (which 9/10 fails) but instead be resourceful within your constraints and to be mindful of what your constraints actually are, which don't have to be new and shiny.
It was a pretty insightful article, I didn't know how a flash game worked internally and how it could be reimplemented! I think it is also relevant for those migrating their projects to newer technologies, I always found this process fun(except there is a deadline) :)
(Edit: I love your games and used to play a lot when I was a kid)
Is it too long, too short, too technical, not technical enough? Boring? Interesting? Is it enlightening or does it just come off like content marketing
Long, but well-organized and not ranty. You can quit after a few sections and still learn interesting things. Technical enough with enough screenshots to keep it from being "wall of text". It is a good way to share some eye candy from your games. [E]nlightening? Yes. [C]ome off like content marketing? Yes, but this is the kind that we want to read -- basically, interesting content marketing. Don't be ashamed that you need to hustle a little bit as a small software shop.
Oh, and you forgot funny. This part made me laugh:
Flash stores its vector graphics in XML format. You might argue that XML is a poor choice for graphics data, but you weren't a product manager at Macromedia. Behold: ...
I’ll add to the chorus and say that this was a wonderful post and the type of content I hope to find when I come to HN.
I enjoyed how you explained certain technical concepts succinctly and using simple language. For example, as someone who never used Flash, you explained the 1000 ft view of how Flash works. When I’m looking at a new tool or framework, I try to star by understanding the mental model behind it. Yet, a simple explanation of it is often difficult to find.
I was also struck by how much technical work was involved here—you made it sound easy. How long did this project take you?
I liked it a lot! It doesn't feel like marketing at all, and I think it's a good balance between technical and non-technical (though I wouldn't mind more details).
Adobe couldn’t figure out how to monetize Flash, other than selling the Flash authoring tool to Flash designers, a dying breed, for a few hundred bucks or bundled in Adobe’s Creative Suite. Adobe tried selling Flash video DRM, which got undercut by Google Widevine, and selling licenses to unlock Flash opcodes for advanced 3D and C++ cross compilation, which was undercut by web technologies like WebAssembly.
Also, I think Flash was more expensive to maintain than Adobe’s other design applications because the Flash Player needed constant security patches. Adobe was usually happy to milk cash cow products, such as Director and Shockwave, transferring maintenance to remote teams in India.
Keep on writing!
I enjoyed reading what you tried and why you ended up with what you did.
It is fine to mention your game, I do not consider that content marketing at all.
It's interesting for sure, I'm left wondering if it was less work to make flash continue to work somehow instead of re-authoring the original games.
I mean you've probably learned a lot, but you could have learned to author games using a more modern tool than flash instead and that would have been useful in the future, right?
Great article! I also still use Flash by using a custom runtime that interprets the output of the “Export as texture atlas” feature. I was wondering if you had attempted to use this feature in order the rasterize the graphics?
Looks like that feature was added in Animate CC, which I don't use, so I haven't tried it.
Looking at the docs, it looks like something I would have at least tried. Might have saved me writing the rasterizer, though I'd still have wanted to atlas everything together into bigger atlases, and make binary animation files.
One downside vs the .fla parsing approach I went with is that even if you can script away the GUI clicking, you'd still have to have Flash open while the build script runs. I quite like having an exporter that is just a CLI program you can run without Flash, though it's not a massive deal.
I'd be interested to see what exactly Animate puts into the animation.json file it generates. The docs don't seem to mention it, and I couldn't find any example ones online.
Your tool looks great, by the way — have you made any games with it?
It is perfectly balanced. It can be read top to bottom in a few minutes.
If you feel like to expand a part you can write a new post and link it from the original one.
Some other posts are born with all the tiny details, are too long to be read on one session and I end up missing even the key points because that second session never happens.
I might have missed this in the article but are you sharing any of your work? I know that a lot of the work was manual but some of your tooling might be useful for anyone else who want to go this craftsman route of converting a flash game.
This was a great read. I distinctly remember playing Hapland as a kid. Armour games or Crazymonkeygames, can't remember which one it was. So this was a great nostalgia trip.
I thought it was great, and I have no interest in games or game development, but I read the whole thing top to bottom and came away thoroughly impressed. Excellent post and work!
Also, the idea of using text/assembly as an intermediate format of binary files is pure genius. I will probably use that occasionally for similar use cases.
