masonremaley

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.)

That’s also a good question.

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.

That's a great question.

I was concerned about this, so I provide the following two APIs:

* https://docs.gamesbymason.com/zcs/#zcs.Entities.chunkIterato...

* https://docs.gamesbymason.com/zcs/#zcs.Entities.forEachChunk

Both of these iterate over chunks instead of entities, and as a result the iterator only needs to advance once per chunk of contiguous entities. The caller is then responsible for calling chunk.view (https://docs.gamesbymason.com/zcs/#zcs.chunk.Chunk.view) to get slices of components from the current chunk, and from there they can either rely on autovectorization or implement the vectorization themselves since they're now working actual slices of data instead of an iterator.

I haven't actually checked if the optimizer is smart enough to work back from the higher level API and realize that it's just an abstracted for loop. I inline some stuff to encourage this, but my assumption is basically that this is an unrealistic thing to expect it to do hence the lower level API. Providing the per-chunk API also isn't really a maintenance burden or anything since the high level API is implemented in terms of it anyway.

There's an argument to be made that I should only provide the lower level API since it's likely more optimal, but IMO it's less friendly & switching to it in the rare instances where it turns out to be a bottleneck should be easy enough.

Is my chunk iterator API similar to where you ended up with, or did you take it a different direction? Feel free to link your project if you want, I'm always interested to see how other people handle this stuff!

The other reply mentioned that vsync can save battery--on top of vsync, Way of Rhea supports syncing to every other vblank, halving the FPS. This will presumably should save even more battery (though the intended use case is to prevent stuttering on computers that can't consistently hit the monitor's refresh rate.) Ultimately, though, no matter what I do I don't think you're gonna be able to play very long on battery power.

For #2--my glasses prescription is so strong that I spent $330 on fancy lenses today in the hopes that they'll distort less around the edges. Wish me luck. (:

I don't have a full answer, but if it helps at all, these are all C APIs--so if you can find a way to call C code from your Java program you should be set.

Yup! I'm aware of what DPI scale is for, I use it when I write game tools. I don't use it in game, though--that's an intentional tradeoff I'm making. It seems like a pretty common tradeoff for games though!

If you want to see why, try mocking up a typical shooter HUD. Now try scaling up/down all the elements by 50% and see what happens. Feel free to play with the anchoring, etc. Chances are you're not gonna like what you see! Things get even more complicated when you consider that players with controllers often change their view distance when gaming and don't wanna reconfigure their display all the time.

The typical solution is to fix the UI scale to the window size, and keep the text large enough that it's readable at a large range of DPIs and viewing distances. If you can't get 100% there that way you'll typically add an in-game UI scale option. (The key difference between that and the built in UI scaling in Windows being that it's specific to the game, so you'll set it to something milder than you'd set the Windows option, and it will only affect the game so you don't have to keep changing it back and forth.)

[EDIT] I think I came up with a way to explain this that saves you the trouble of drawing it out yourself. The fundamental issue, view distance changes aside, is that games are balancing a third variable most apps don't have to: how much of the background--the actual game--is the UI occluding?

It's not, in my codebase, but I'll edit that when I have the chance so nobody blindly copy pastes it and ends up with something super broken

Hmm. I think I tried calling into their API to rule that out--but, it's been a while, so it's 100% possible I remember incorrectly which would explain why it didn't work!

That's a good point--I'll look into whether Microsoft has any guidelines on this, and add a disclaimer to the article when I get a chance.

It's possible I'm misunderstanding the docs, but here's the line that lead me to believe linking to one of their libraries alone would be enough (and lead to my surprise when it didn't work):

(https://docs.nvidia.com/gameworks/content/technologies/deskt...)

> For any application without an existing application profile, there is a set of libraries which, when statically linked to a given application executable, will direct the Optimus driver to render the application using High Performance Graphics. As of Release 302, the current list of libraries are vcamp110.dll, vcamp110d.dll, nvapi.dll, nvapi64.dll, opencl.dll, nvcuda.dll, and cudart..

Yup, you hit the nail on the head (author of the article here). I guess I could've clarified that, I didn't expect people to assume I was advocating against scaling your UIs to fit the user's screen! Many games scale to fit the window by default, and even offer additional controls on top of that.