3 ms·
Most software things become simple when you can define them down into an enumeration of possibilities. For example, if my text problem were "display these pref
by syntheweave 4y ago
Most software things become simple when you can define them down into an enumeration of possibilities.
For example, if my text problem were "display these preformatted strings in a single resolution and layout" there would be no requirement on their encoding or processing and I could do whatever I like, even hardcode them or store them as image assets. Games have done this trick since forever because they have a tremendous capacity to soak up more and more static content, and much of the core tech in a game engine is in finding the ideal representations to efficiently load and present that content while carefully minimizing the dynamic behavior that would entail a general-purpose solution.
The problem for software in the larger view of things is always that we've defined the problem with sufficient generality that it has to accommodate all the depth, because we don't know who is using the software or what they want from it. The medium is never "set in stone" so the tools are forever adapting to a new use case. And just when you think you've modelled every possible aspect of the data, some other way of doing it will come up.
And it's not a right thing either to think "OK, I'll just solve the most general thing I can think of now so that I don't deal with it later" because then you just have a wide field of untested edge cases and no coverage of the thing you didn't anticipate.
Like, take image editing software as an example. They all let you draw things freehand. Many support pressure sensitive stylus input. But the way they interpret that input is all over the map: different sensitivity curves, stabilization algorithms, brush behaviors and so on. There's no winning the battle by defining the most general engine for freehand drawing and painting, because what the user craves most of all here is the path to "just works" defaults. Thus in every sufficiently developed editor, an enumeration of possibilities appears again, but as a configuration letting you browse presets.
- _gabe_ 4y ago> Games have done this trick since forever. Text rendering is still a very complex task in modern games unless you're using an engine (and even then the complexity is still there it's just hidden). I'm not aware of any recent releases that stored all their text as hard coded images. Most games will at the very least create a predefined charset, render each character to a bitmap or sdf as part of the loading using something like freetype or stb_truetype, cache the bitmaps or sdfs to a hash map with a lookup ID and all that stuff, upload the images to a texture on the GPU, perform some sort of layout scheme when rendering the text in the game world or HUD (which includes things like figuring out the kerning for different characters, line wrap, and all the other fun stuff). Like somebody else mentioned, nothing is simple. Even a bitmap font from the 80s was wayyy more complex then it would be today because of all the optimizations you would have to create to make sure it was fast, and the extreme lack of modern rendering utilities that we have today.* *I wasn't alive in the 80s, so this is just based on the videos I've seen of what we had then and articles/books I've read about what programming was like then.
- __del__ 4y agobitmapped fonts are pretty damn simple, but you can compress them by storing only the pixel distances to the next inversion from 0 -> 1 or 1 -> 0 along scanlines