why does angband still use .fon files ?
 

I was looking at -
I remembered that font files used to be a thing during windows 3.11. Looking up on the web, for sure they are windows era fonts https://fileinfo.com/extension/fon

There are so many foss fonts nowadays . Just to ideate there are 514 packages (font number will be higher in Debian) .

See -

It would be nice if we can move from .fon to either .ttf or .otf or .off fonts depending upon people's tastes.

https://en.wikipedia.org/wiki/TrueType
https://en.wikipedia.org/wiki/OpenType#Open_Font_Format
https://en.wikipedia.org/wiki/OpenType

They also will work better on mobiles and SBC's if it were deployed as most platforms have support for all three font formats shared.

The answer to a lot of questions like "why does Angband still do X?" is because no-one made it not do that yet. Plus, I think most of the Angband maintainers have enjoyed hacking on the game and weren't/aren't particularly interested in learning how to write e.g. a new Windows frontend, or learning how to use SDL. The platform-specific bits of Angband are for sure the least modified and least loved bits of the game. Pending people who like frontend work showing up and doing some stuff, the frontends mostly stay unmodified for years at a time.

EDIT: Also, Angband is very different on different platforms. Windows and SDL use the .fon files, but Mac doesn't, and neither does the X11 port, or curses.

hmm... @takkaria, while I can understand that, I do see the following in the debian angband package


Could anybody share what are the different fonts that are used or just one font with different sizes ?

If it's the latter, we could simply use one or more fonts to make the game look attractive without much cost.

I have 806 fonts when I have not installed all the font packages in Debian archive -

There is also fonts.debian.net (no longer available) but available through archive.org which could help us in getting a good replacement.

Unicode fonts could be another idea perhaps https://en.wikipedia.org/wiki/Unicode_font

One idea could perhaps be to use the popular noto font which is used quite a bit.

https://web.archive.org/web/20160303...ts.debian.net/

The simplest explanation for this is that the Linux build still includes resources that it does not actually use.

They're used by the SDL port, I think.

They are all different fonts, and the user chooses which ones they want for which window in the SDL and Windows ports. Personally I find the bitmap fonts more legible for text mode than outline/vector fonts but YMMV.

Takkaria--i agree bitmaps were better choices with low resolution screens. But those are few and far between these days. Spline-fit fonts are a much better choice now.

.fon files are really just tilesets. IMO, it would be easier to use bmp or png file with glyphs + text file with coordinates (exactly like tiles in lib/tiles).
In fact, for my project, I've written a tool that makes such tilesets out of vector font files :) If someone wants it, I can send it to you (the tool is written in D, so you'll also need a D compiler from https://dlang.org/).

t4nk-
It turns out to be a performance penalty to use tiles instead of glyphs. You can see the difference when running and sometimes on redraws.

Do you have any proof of that? Glyphs, as displayed on monitors, are pictures. If they are pictures to begin with (like in .fon files), they're tilesets. If they're something else (say, Bezier curves, like in .ttf files), then transorming them into pictures (rasterizing) requires additional work*.

I can, except in the opposite direction: the difference is that pre-rasterizing glyphs of vector fonts and making an in-memory tileset improves performance noticeably (e.g., main-sdl2.c:make_font_cache()).

* which is, btw, not trivial and can involve such things are running bytecode on a virtual machine (part of so-called "hinting")...

It can be surprisingly difficult to render a large grid of anything without getting performance penalties. I discovered that when writing the Pyrel UI. The naive approach (just tell your GUI widget library to render a text symbol for every tile in view on every update) is horrifically slow. Getting clever about remembering which portions of the screen have changed and only rerendering those helps, but then scrolling the view is also horrifically slow (because every single tile "changes"). So then you start saying "well, the scrolled view re-uses a lot of tiles from the previous view, so I'll keep the previous view around, redraw it at an offset, and then draw the new/updated tiles on top of that" and you have fairly complex drawing logic that's still really not all that fast.

As for tilesets vs. software-rendered fonts, I can absolutely believe that it's faster to blit a texture to a tile than it is to draw an "@". After all, drawing the "@" involves first converting the vectors to a raster image and then...converting that raster to a texture and blitting it. :) A pre-rendered tileset of the kind t4nk describes is super common in gaming. You can load the entire tileset into your GPU's memory and then just send a payload to the GPU saying "render this tile here, render that tile there", and it can draw the entire screen without having to go back to the CPU for more information.

If I understand what you mean, I would be surprised by this. If you're doing a simple one-pass render where you just blit from "internal game map" to a load of glyphs on a pixmap, there shouldn't really be issue here. (This was also my experience with my experimental port of T2 to Allegro. I had more issues with SDL2, but that had more to with keyboard handling than display performance.)

Oh, it's true and has been since about... ever. The only situation I can think of where it wouldn't be is if you're actually rendering so many different combinations of glyphs/fonts/colors/background colors/etc. that it's infeasible to cache them... but once compositing arrived the only things that remained an issue was the number of unique glyphs + fonts. Almost everything else can be done trivially (and insanely fast!) with compositing during the blit operation.

(And let's not even get started with shaders... :) )

As I recall (and this was awhile ago so I may well be misremembering), I was drawing each tile individually. Like, a # goes at (0, 0), that's one draw call. Then a . goes at (1, 0), that's a separate draw call. Etc. It was the sheer number of draw calls that was killing me. Of course, that's a pretty silly way to draw text, but I probably felt it was necessary in order to handle color displays or something like that.

Were you drawing to the screen or to a backup buffer? As earlier post says, doing the latter, then blitting everything into place makes a big difference (and eliminates the flicker.)

Oh sure, I'm well aware of double-buffering. I think I was CPU-bound though.

If you're really curious, the Pyrel code is still up on BitBucket.

Ah, right it was 1 Python function call per glyph then? I'm not sure about Python specifically, but in many languages going across the "VM" -> native barrier can be quite costly, so if you were incurring that cost for every tile then it's suddenly starting to make a lot more sense :).

There's also just the fact that the standard Python interpreter is itself quite slow compared to native/JIT'ed languages and even compared to Lua IIRC.