If that's not "Hacker" News, what is?
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?
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.
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.
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 :(
they are, but on nvidia only... https://developer.nvidia.com/gpu-accelerated-path-rendering
But signed distance fields work well and easily on GPUs.
Here's a recent article and discussion about it:
Vector graphics on GPU (gasiulis.name)
235 points by mpweiher 4 months ago | hide | past | favorite | 95 comments
(OK those links are for NVidia, but if they can do it I guess others can too ?) (also see https://www.researchgate.net/publication/262357352_GPU-accel... )
I've seen some font rendering work that has already embraced them for high perf rasterization.
Still, may be hard to get flash equivalency.
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.
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
Can you elaborate on this?
https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long...
Can have.
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).
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.
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.
(Edit: I love your games and used to play a lot when I was a kid)
It's an impressive piece of writing. You're definitely good at this.
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
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 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 second that. I find the better someone knows a subject, the harder it is for them to provide this perspective, making it all the more impressive.
Keep writing!
Did you investigate Haxe or OpenFL?
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.
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?
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?
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 wish the Hapland series was coming to Mac, but I respect your decision to snub Apple.
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.