A 32pix glyph produced by BMFont is not the same as the glyph in the first mipmap of a 64pix glyph. I guess hinting plays a part in this incongruity. In any case, as I've observed (and as is expected) the glyph produced by BMFont is of higher quality. So I suggest adding the option of generating mipmaps using the appropriate system font when exporting as dds.

issues:

texture size would have to be a multiple of 2,

there would have to be adequate spacing between the glyphs,

the font size would determine the mipmap chain (e.g. no mipmaps for a font of size 25, as it's not divisible by 2).

p.s. I tried doing that manually but BMFont changes the arrangement of the glyphs so I'd have to cut and paste each and every glyph, for each mipmap level.

The mipmaps should be generated from the texture itself by shrinking it. The font descriptor file should be the same for each mipmap as the only thing that changes is the scale of the texture.

When generating the bmfont remember to use enough padding for the glyphs so that they do not blend into each other in the smaller mip levels.

The mipmaps should be generated from the texture itself by shrinking it. The font descriptor file should be the same for each mipmap as the only thing that changes is the scale of the texture.

When generating the bmfont remember to use enough padding for the glyphs so that they do not blend into each other in the smaller mip levels.

Yeah, I know, but my point is that a glyph generated by shrinking-supersampling is not as good as a glyph straight from BMFont.

That's true. Shrinking the textures for mipmapping tend to blur the characters a bit.

However, generating the characters for each mipmap level using smaller font sizes will not work as the characters do not keep the same proportions and properties. You would get a crisper looking text, but the spacing between the characters would be all wrong, sometimes too large and sometimes too small.

Now it would be interesting if BMFont natively supported distance-field fonts (I keep repeating myself, sorry).

Because in this case, not only would the quality already be quite good without mip-maps (both when mini- and magnifying), but you could actually generate mip-maps that do not cause the font to appear blurred at small sizes at all, not even in theory.

A mip-map could be a smaller distance field that is generated from the original 8-10 times over-sized image in the same way mip level-0 is generated (instead of down-scaling the level-0 image). Same, identical process for the level-1 (and further) mip-map, well... except the image is half the size in every dimension, obviously.

That should actually work perfectly, giving crisp fonts both at minification and magnification, even when interpolating between mip levels (since the hardware linearly interpolates between two lengths, each of which is valid at its resolution -- this should interpolate perfectly).

Are mipmaps useful for distance fields? Mipmaps are used to reduce aliasing as the texture sampling distance increases the smaller the drawn triangle is, but it would seem that the way distance fields work this wouldn't really be a problem.

Are mipmaps useful for distance fields? Mipmaps are used to reduce aliasing as the texture sampling distance increases the smaller the drawn triangle is, but it would seem that the way distance fields work this wouldn't really be a problem.

True, distance field textures don't look all that bad when minified. You can see some aliasing artefacts but they're not nearly as apparent as with normal textures as long as you don't minify too much. Up to half the original size, linear interpolation works nicely (and since it's distances, the end result of averaging 4 texels is even correct!). Beyond half the size, it slowly starts looking worse.

However, one valid reason for mipmaps would be that you immensely save on texture cache (and bandwidth!) if you're using a mip level that is only 1/4 or 1/16 the memory footprint.