After publishing this I wrote another crash reporter for a freelance client, but it was much more involved because that project doesn’t ship debug symbols to users so we had to do symbol resolution server side, which precludes using the closed source platform specific tools for this on macOS, iOS, and Windows. On Linux it’s easy of course.
I’m going to do a followup post at some point with what I learned from that project because it was much bigger. The TLDR is that IMO there’s a gap here I’d love to see an open source project fill. I don’t have time to start it right now, and my recommendation if you don’t want to get too in the weeds is to ship symbols with your executable and bypass a lot of the work.
(Edit: This didn’t answer your direct question sorry. I looked at both Crashpad and Breakpad when I started the second crash reporter and decided against both, but I don’t quite remember why.)
I personally wouldn’t compress pixel art—the artist presumably placed each pixel pretty intentionally so I wouldn’t wanna do anything to mess with that. By pixel art’s nature it’s gonna be low resolution anyway, so storage and sample time are unlikely to be a concern.
Pixel art is also a special case in that it’s very unlikely you need to do a bake step where you downsize or generate mipmaps or such. As a result, using an interchange format here could actually be reasonable.
If I was shipping a pixel art title I’d probably decide based on load times. If the game loads instantly with whichever approach you implement first then it doesn’t matter. If it’s taking time to load the textures, then I’d check which approach loads faster. It’s not obvious a priori which that would be without measuring—it depends on whether the bottleneck is decoding or reading from the filesystem.
Good question. I don’t have any authored SDF content right now so take this with a grain of salt, but my thoughts are:
1. Fonts are a very small percent of most games’ storage and frame time, so there’s less motivation to compress them than other textures
2. Every pixel in a font is pretty intentional (unlike in, say, a brick texture) so I’d be hesitant to do anything lossy to it
I suspect that a single channel SDF for something like a UI shape would compress decently, but you could also just store it at a lower resolution instead since it’s a SDF. For SDF fonts I’d probably put them through the same asset pipeline but turn off the compression.
(Of course, if you try it out and find that in practice they look better compressed than downscaled, then you may as well go for it!)
[EDIT] a slightly higher level answer—you probably wouldn’t compress them, but you’d probably still use this workflow to go from my_font.ttf -> my_font_sdf.ktx2 or such.
I’m going to do a followup post at some point with what I learned from that project because it was much bigger. The TLDR is that IMO there’s a gap here I’d love to see an open source project fill. I don’t have time to start it right now, and my recommendation if you don’t want to get too in the weeds is to ship symbols with your executable and bypass a lot of the work.
(Edit: This didn’t answer your direct question sorry. I looked at both Crashpad and Breakpad when I started the second crash reporter and decided against both, but I don’t quite remember why.)