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

[Derakon]

Originally Posted by AnonymousHero

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

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.

[Pete Mack]

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

[Derakon]

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.

[AnonymousHero]

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.