Geep

This last month, I've been exploring TDM's font situation, and improving the documentation as I go. In the wiki, "Font Conversion & Repair" was rewritten, with parts broken out and expanded as: Font Files Font Metrics & DAT File Format Font Bitmaps in DDS Files ExportFontToDoom3 Q3Font Refont As announced earlier, that last item is a new C++ console utility for revising font metrics in DAT files; essentially another alternative to Q3Font and Font Patcher. It now has additional functionality that provides font-coverage analysis. A summary of current results across all TDM fonts is reported in the forum thread "Analysis of 2.12 TDM Fonts". Also, refont allows its human-readable outputs to be decorated with an annotation for each character (out of 256 codepoints). Associated with that, I've just created and released 4 annotation files: 1 Cyrillic version for TDM's russian map 3 variants for TDM's custom english/european char map. One of the variants was derived from another new mapping file that is now available from existing wiki article "I18N - Charset". Within that file is a list, in a standard format, of the 256 TDM bitmap codepoints mapped to the corresponding Unicode U+NNNN value and name. This may be useful in defining TDM's mapping to TTF font editing programs. For all these wiki pages mentioned, I imagine there will be additional cross-links and tweaks. But pretty much done.

I've added your much better description of the process to the existing mention of resizing speakers in https://wiki.thedarkmod.com/index.php?title=Setting_Up_Speakers#maxDistance%2F_s_maxdistance

To the "Path Nodes" wiki article, I've added a few sentences about path_follow_actor. It mentions that it currently doesn't support the actor being the player, and has pointers to the new bug report and the workaround given in this thread. The entry for path_follow_actor in the Entity Database now reads "... actor (= other AI, not player)...

That was just a "nice to have", not "must have". No worries. Nor I.

Thanks, looks useful. Except datetimes look like all Jan 24, 2024, presumably when the archive was formed, not when file edit was done. So it goes.

I thought that might be the case. I don't believe I can access the SVN. Could you zip up all the font stuff you can easily find in that archive and send a link to me? TGA/DDS, even TTF for Stone, Mason, Carleton, etc., etc. No hurry. Thanks. P.S. Try to preserve file timedates

I'm guessing there's a way to do that. Then back to DDS to distribute. That process would still cause an extra generation of quality loss, but at least you'd have a TGA in hand, for iterative editing without cumulative losses. But maybe first ask long-time TDMers to hunt for archived TGAs.

Because DDS is a lossy format, every direct edit of a DDS file may reduce its quality slightly. So that means either: hunt down the corresponding TGA file with the same timestamp otherwise, edit the DDS as few times as possible. In the case of Stone, if the TGA can't be found and editing DDS is needed, I'd want to think about batching up all the bitmap edits needed for i18n... but that's a lot of work. I might add, there a third possibility in the case of the readable fonts that are currently ASCII only. If they were sourced from TTF, and you find the TTF (easy in a few cases), then see if it covers Latin-1 or more. You can (with some complications RE the conversion software) regenerate an improved TDM font from that.

I'm assuming we're talking about Stone 24pt font here, used in subscripts & elsewhere. Images of letters are arranged into a bitmap by a process that doesn't have to conform to a tidy alphabetic grid. See Figure 2 of my new article https://wiki.thedarkmod.com/index.php?title=Font_Bitmaps_in_DDS_Files In the figure, you can see there's an accented "a" to the left of the W, whose foot is presumably within W's bounding box. I think I looked at this earlier & concluded that I couldn't shrink W's bounding box enough in the DAT file. So probably the pixels of the W need to be moved to the right... I haven't tried such surgery yet.

I have updated my Refont program, to now have a function that can analyze a font DAT file for missing or problematic characters. As part of a broader inquiry, I've just applied that program, individually, to all current 'english' font DAT files. I'm reporting the overall results here. I'm sure this will not be a surprise to some of you, but may be to others. Background As you know, TDM fonts are based a bitmap system, derived from 256-character code pages, of which "English" and "Russian" are currently supported. "English" is actually Latin-1, with additional characters to cover more European languages in a single codepage. This is (in theory) quite good for major European languages, less so for less-prominent ones. For each font, bitmaps are distributed in 3 sizes (12, 24, 48 pt), with the engine doing interpolation scaling. Current Font Findings 12-pt Size for All Fonts Only ASCII (i.e., lower range 0-127) characters are provided, no European. For some fonts (stone, mason, mason_glow), the 12-pt DAT is not distributed, so the engine will substitute a larger size, which typically has better Latin-1 coverage. For Fonts Used in Main Menus, HUD, or Subtitles The numbers shown approximate the number of "characters needing work" Fontname Size-24 Size-48 carleton 20 16 carleton_condensed 20 35 mason -- 33 Since 24 pt is not distributed, engine uses 48 pt. stone 30 83 For Additional Fonts Used in FM Readables, Etc. Except for one font (treasure_map), all the remaining fonts are ASCII-only, i.e., no characters in the upper range. In the lower range, routinely the 24 and 48 pt sizes have equivalent coverage. Most of these fonts are fully or nearly complete, while some neglect certain punctuation symbols. The worst is "everette", with 24 "needing work" characters. Further details are here:

This was overall an enjoyable FM for me. Thanks for making it. Thoughts/spoilers: Also, there were 2 minor issues undoubtedly due to engine or asset shortcomings:

That would be another good method. The one I used was easier for me, given that I was also supporting a SFW difficulty level where she is already dressed before reaching the attic. Thanks. No animation available for that either, so all done with cut-scene fakery and video editing. Glad you enjoyed a bit of sparks with those. Although I can't take any credit for the idea of dress mannequins with human hands... you'll see them IRL at any mall. But the implementation in TDM... therein the magic: It's 11pm here, and I'm off. Thanks for chatting.

That "fall" delay was by design. Because there is no animation available to show her actually re-dressing from the trunk of clothing, so instead I wanted you to have to imagine it. Rather than actually catching up with her and seeing the instant body swap.

They are a riff on historic mushroom-style "linen smoothers", as this article sketches: http://www.oldandinteresting.com/antique-irons-smoothers-mangles.aspx The gold color hints at heavy brass. Bonus in the NSFW difficulty setting: One is also seen outside a laundry setting, for its *snort* suggestive shape.

I have just released a new utility, "refont", as an open-source, partial-successor of the traditional "q3font", used to tweak the spacing and placement of TDM's bitmap font characters. For the whole story, see the new wiki page Refont.

I have just released a new utility, "refont", as an open-source, partial-successor of the traditional "q3font". For the whole story, see the new wiki page Refont. (I'm gonna post this in a few forum threads. Don't hate me for that.)

I have just released a new utility, "refont", as an open-source, partial-successor of the traditional "q3font". For the whole story, see the new wiki page Refont.

Yeah, it's J anky, but can't be fixed in the DAT file. Likely it requires moving pixels in the bitmap. I'm personally unenthused about doing that, particularly in a 2.12 timeframe.

Yet another Stone 24 pt Update. This removes stray marks to the left of G (as well as char 249, u with accent grave), visible with textscale 0.25 but not 0.24. So this may or may not benefit subtitles, but it will definitely help Stone font readables. Most of them use a scale of 0.25 for body text. An attempt was made to also improve G spacing, but (since xSkip can't be changed) effect is marginal at best. fontImage_24.dat of Feb 27

OK, I poked around a little further. At the moment, beta5 is what I have installed. testSubtitlesANSI ships with an override of tdm_subtitles_message.gui, which allows easy adjustment of textscale. The shipped textscale is set to 0.24. With that, the stray marks left of G are not visible. If you change it to 0.25, they are visible; which is evidently what your custom gui is also using. If you setaside any custom tdm_subtitles_message.gui, then the core one goes into effect. Which, for beta 5, uses a textscale of 0.24 I don't know whether we will be going with 0.24 or 0.25 for the release. Nevertheless, now that I can see the stray marks, I'll see about fixing them. BTW, with your gui, the black outline shadows have the effect of enlarging the stray marks as black smudges. Helpful for diagnosis.

I just looked at capital G. I didn't see any stray marks. The spacing to its right was a bit larger than required, but I didn't think grossly so. Is that what you were referring to?

Here is the release of testSubtitlesANSI , one of my tools to test and improve the Stone 24 pt font that is used in all the English subtitles. testSubtitlesANSI.pk4 of Feb 25, 2024 As the screenshot below reveals, this testing tool is an FM that's a variant of that used to develop subtitles for individual AIs. Here, the subtitles are just alphabetic lists. There are 7 subtitles that cover all the TDM 8-bit codepoints (e.g., 0-255), including those representing European languages. The first two subtitles (i.e., codepoint sub-ranges) are shown in this screen shot. The tool allows inspection for stray marks and inter-character spacing; black walls & floor facilitate that. This release includes the most recent improvement to these attributes, provided in yesterday's update of the fontimage_24.dat file. (The changing of those attributes was done with a different tool, used iteratively with this one.)

Oops, in that last release, I accidentally didn't check character spacing in the codepoint range 128-159. And sure enough, there were problems with character 131 & 132, which needed 4 more pixels of horizontal box shifting than the 3 pixels they got earlier. So here's a better version: fontimage_24.dat of Feb 24

Here is another update to the English Stone font's DAT file used for subtitles and some readables: fontImage_24.dat This supercedes the Jan 30th update. As agreed, now all character spacings - as given by xSkip - are preserved (from this file in TDM 2.11). Exception: the Jan 30th repair of garbage metadata for "<" and ">" remains, including xSkip repair. ASCII Characters (lower 128). The earlier Jan 30th post summaries those ASCII characters that needed metadata changes to avoid adjoining stray marks. (The detail report below updates newer reversions and minor revisions.) ANSI Characters (upper 128). An analysis was also made of the status of the Stone 28 pt font's characters in the upper codepoint range of 128-255. This could be of interest if the subtitle system was some day expanded to include European languages, and continues to use the historic codepage method. The analysis also prompted some additional DAT tweaks now. Broadly, implementation of the upper-range characters (standard or TDM-specific, as defined in the TDM wiki's I18N - Character mapping I18N) is incomplete for Stone 24 pt. The status is: 43% (55 chars) Good as is. 9% (12 chars) Good enough after DAT tweak included in this update. 6% (7 chars) Missing and shown as hollow box. 30% (38 chars) Missing accent/diacritic. 7% (9 chars) Otherwise weird. But often suggestive of glyph work started but not completed. In addition, 7 chars within categories (3-5) were "improved", but are still not good. To really solve categories (3-5) requires DSS bitmap surgery (and corresponding DAT adjustments), which is beyond the scope of planned work. DAT tweaks of ANSI characters (like with ASCII) were careful to avoid changes to xSkip. Tweaks can be further grouped by problem solved.... In category (2): - (4 chars) Char is clipped, with stray mark from adjoining character on other side. - (7 chars) Stray mark, without char clipping. As improvements in categories (3-5): - (3 chars) Stray mark, without char clipping - (4 chars) Out of valid range on top edge A categorized itemization about treatment of specific problems and characters, with further details, is here: Information about methods, including new tools, to conduct this analysis and tweaking will be forthcoming, mostly after the 2.12 release.

It's hard. I see what you are thinking about is a "bullet point" pattern, with or without a bullet point character. For that case, I suppose what we are trying to detect is: - the line starts with the bullet point pattern - a "J" character (say) with a shortened spacing, is somewhere in the line. - the line itself in the xd file is long enough to force a word wrap (let's just think about a single wrapping here) - the author assumed a particular word wrap point, and put in extra spaces in mid-line, immediately at the wrap point, so as to indent the latter part of the line, aligning with the indent of the first part. - the shortened-spacing J screws up the resulting alignment. Probably would need a script/program to winnow this down... ideally, that algorithm could also restrict attention to just Stone font. I'm OK with putting such an effort off for now, maybe revisiting it for 2.13.