One Missing Glyph Cost 16 MB: How Foxy Dumplings Cut Font Atlas Memory From 48 MB to 4-8 MB

Foxy Dumplings is a cozy cooking and management game about Lisa, a professional chef recovering from burnout by starting over with her family's dumpling recipe and a food truck. Players travel through 12 locations inspired by real food cultures, grow ingredients, learn regional recipes, run the truck, and invent their own dishes. It is built by the four-person core team at Soft Crunch Games, where Grzegorz Wątroba handles all programming, platform ports, build pipelines, and certification work. The project targets PC via Steam, GOG, the Epic Games Store, and the Microsoft Store with Xbox Play Anywhere, plus Nintendo Switch 2, Nintendo Switch, PlayStation 4, PlayStation 5, Xbox Series X and S, iOS, and Android, with launch planned for

2027. It runs on Unity 6.3 LTS.

One rule governs the whole project: every platform gets the same game from the same commit. There are no separate branches and no mobile edition arriving half a year later. That discipline is what makes the font story worth stealing, because the same discipline produced it: the team supports 14 languages, including Chinese, Japanese, Korean, and Thai, each with its own font atlas.

A font atlas is a texture sheet that holds the glyphs a game needs to draw text. A static atlas is baked in advance with a fixed set of characters. A fallback atlas is where characters go when the font being used does not contain them. Unity's TextMeshPro documentation describes the same mechanism in general terms: a font atlas can only hold a certain number of glyphs, and the fallback system searches other font assets when TextMeshPro cannot find a glyph in the text object's font asset. That is the normal, documented safety net. In Foxy Dumplings, the safety net was sized wrong.

The team saw memory spikes during language changes. That sentence deserves a pause, because it is the kind of symptom most teams wave away. A language switch is a rare, one-off action. A spike during it is easy to blame on loading, on the new language's assets, or on nothing at all. The team did not guess. They profiled the allocation path.

Characters missing from the static atlases were rasterized at runtime into oversized 4096 by 4096 fallback atlases, with a full 16 MB atlas re-upload for every new character. Read that mechanism slowly, because it contains two separate costs multiplied together.

First, the rasterization happened at runtime, during play, instead of at build time. Every character the static atlas did not cover became fresh work the moment it appeared on screen. Second, the fallback atlas it landed in was 4096 by 4096, and adding a character re-uploaded the whole atlas, not just the new glyph. One new character, 16 MB of upload. Then another character, another 16 MB. The cost was not proportional to the size of the new glyph. It was proportional to the size of the entire page it landed on.

This is why the spike showed up on language switches specifically. Switching languages is exactly when a flood of characters the current atlases have never drawn suddenly needs drawing: new menus, new dialogue, new item names, all at once, in a writing system the previous language never touched. For Japanese, with its large character set, the flood was biggest, and the reported number shows it.

The Unity Blog reports the re-upload figure as 16 MB for a 4096 by 4096 atlas. That figure is consistent with a single-channel atlas page: 4096 times 4096 equals 16,777,216 texels, which is 16 MB at one byte per texel. This arithmetic is our check on the blog's number, not a separate claim from the blog. A 2048 by 2048 page is 4,194,304 texels, about 4 MB at the same one byte per texel. So the reported result of 4-8 MB per font after the fix corresponds to roughly one to two 2048 pages per font, where the same fonts previously needed about 48 MB of new atlas memory for Japanese. The exact page count per font depends on how many glyphs that font actually needs, which is why the blog reports a range, not a single number.

Part one: regenerate the fallback fonts with 2048 by 2048 pages. Shrinking the page quarters the cost of every re-upload, because the re-upload cost is the whole page. A 16 MB penalty per new character becomes a 4 MB penalty per new character, before anything else changes.

Part two: add glyphs in batches before the switch. This is the part most write-ups would skip, and it is the part that actually removes the spike rather than just shrinking it. If glyphs are added during the switch, the switch itself pays the rasterization and upload cost, in front of the player, at the worst moment. If glyphs are added in batches beforehand, the cost moves to a moment the team controls, and the switch itself stops generating fresh rasterization work. Smaller pages make each upload cheaper. Batching before the switch stops the switch from being the moment uploads happen.

The reported result: the new atlas memory for Japanese fell from about 48 MB to 4-8 MB per font. Both numbers are team-reported through the Unity Blog, not independently benchmarked by us. What we verified is that the mechanism is coherent, the arithmetic checks out, and the fix addresses both halves of the mechanism: page size and timing.

The font fix did not come from a font expert arriving with a font answer. It came from a profiling habit the team applies everywhere. Wątroba's process, as described in the same blog post, is: make a development build on the actual device, attach the Unity Profiler, find what is expensive, measure it, fix it, and measure again. He puts it as, The device is the king.

The same habit caught a different waste in the same project. Some kitchen effects were rendered into a 4K render texture and composited over the UI, unnecessary on a 1080p or 720p display. Changing the render textures to follow the actual screen resolution, and disabling HDR and depth textures the game never used, cut that layer to about 8 times fewer pixels per frame on Steam Deck, and its render texture dropped from about 32 MB to about 4 MB, with no visible change. Same pattern, different system: find the allocation, check whether its size matches what the screen actually needs, shrink the container, and measure again.

That is also why the font numbers deserve trust but not worship. They are one team's measured result on one game, reported through Unity's blog, with the mechanism and the arithmetic both checkable. They are not a promise that your game will see the same ratio. Your glyph counts, your fonts, and your page sizes decide your ratio.

Sources: Adam Axler, How Soft Crunch Games Built Foxy Dumplings For Every Platform, Unity Blog, October 16, 2026; Unity TextMeshPro documentation, Fallback font assets; Unity TextMeshPro documentation, Dynamic font assets; Unity Manual, Introduction to font assets. All numbers in this article are team-reported through the Unity Blog or arithmetic checks on those numbers, as labeled in the text. No new benchmark, frame rate, or test result has been invented for this article.

This article contains no affiliate links. All timings and memory figures are attributed to their sources in the text; no new benchmark, frame rate, or test result has been invented for this article.