Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(1 edit)

Tremendous work. Some of these are downright gorgeous. If anybody is on the fence about this pack, it's a bit pricey but you won't find a better one(although with 175 fonts, it works out to around 57 cents per font, which ain't bad). No matter what your games vibe is, there's a font that fits it. (Also, this is the only one I've seen that provides bitmap font data that includes non-ASCII characters and kerning info... real great)

That said, if Chevy is reading these, I have two suggestions for a future version of this (seems unlikely but I didn't expect a second pack either):

1. A more trivial comment is that it also might be worth stripping unnecessary whitespace from the JSON (and probably XML) in the `packed/` folders, so that it can be used more directly.

2. In a future pack, a monospace font with exactly a 1:2 width:height ratio (for example, width=7 height=14 or width=10 height=20) is something that i'd love. Makes rendering easy in traditional roguelike games that have 'tiles' modes. Still, it's pretty minor.

Thanks for the feedback! I like the idea of a font with roguelikes in mind, that’s a great idea.

For the JSON/XML, how come you want the whitespace stripped? Is it a load time bottleneck for your tooling? 

When converting these to runtime sprites (which is how modern games and game engines render fonts) the empty whitespace ends up being transparent pixel overdraw, very bad for performance. Essentially you want the quads the correspond to the letters to be as small as possible, every pixel rendered (including transparent ones) costs GPU time.

I'm not speaking for tcsc, but I am speaking for myself and honestly all games that runtime render fonts. The extra computation would happen in 2D pixel-by-pixel rendering as well.

Ohh I see. When programmers say “whitespace” they usually mean invisible unicode characters like space and tab. There should already be tightly-packed atlases provided with the asset packs, with associated data files providing each glyph’s atlas position and size/offset, which should allow any renderer to draw the sprites with no excess transparency.

If there are rectangles in the atlas that are larger than the glyphs they represent, that should be considered a bug, so let me know which ones do so.

Aha. If the rects are the size of the glyphs then that's perfect :)