why does angband still use .fon files ?

[AnonymousHero]

Originally Posted by Derakon

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.

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.)

Originally Posted by Derakon

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 "@".

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... )