Geep

File Update for Improved Subtitle Font As requested a while ago, to address the stray marks and other problems seen with current subtitle font, Stone, I am providing a short-term fix for characters in the printable ASCII range 32-126, using corrected metadata: fontimage_24.dat This is intended to replace tdm_fonts01.pk4\fonts\english\stone\fontimage_24.dat No change is needed in the related .dds files for this. Briefly, problems with stray marks found to the left of a character were due to picking up pixels from an adjoining character in the glyph bitmap dds files. Adjusting the location of the source box and related metrics fixed these. Affected were: % C E T W Y | The | character also got improved spacing, as did J Finally, the entirely screwed data for the angle brackets was corrected. This coming month I hope to work up a wiki page with diagrams to better explain what I learned about the mysteries of the idTech4 font .dat and .dds files. To see what the results look like with corrected fontimage_24.dat in place (as an override), here is my testing FM: testSubtitlesASCII.pk4 A longer-term fix (beyond 2.12 release) would also address ANSI and TDM-specific-mapped charaters in the range 128-255. To look at that, I have a similar experimental tester for ANSI (unripe to release). It shows substantial issues in that range. And then there's also consideration of fontimage_12.dat and fontimage_48.dat. And the russian-character variant.

Yeah, I had the benefit of a vocal script for most utterances, to decipher what they were saying. In a few cases, I had to listen over and over, and then make a best guess. Their chatter usually makes sense, but not 100.000%

Maybe it would be possible for the user to just bind a hotkey to toggle subtitles on/off?

Related to looking into the stray marks associated with Stone font characters... I've noticed that the nominal 12 pt DDS (which as discussed above only kicks in under 8 pt) has only ASCII glyphs... nothing with code points above 127. Maybe that's why the corresponding 12 pt DAT file was not distributed, as a workaround to force the engine to use 24pt instead, because tels never got around to finishing the low-priority aspects of the project. The 24 pt DDS does have the ANSI glyphs. At a glance, most are fine; a few are a bit ragged. I didn't check compliance and completeness with TDM's character map as given on the wiki. I don't feel ANSI improvement is a 2.12 item. I've got a test FM to show all the characters. At some point, after refinement, I'll post a link.

It's another aspect of, over time, tailoring the degree of subtitles shown to reflect the needs and preferences of the individual player. I think some low-hearing/audio-off players might appreciate brief soundscape descriptions, including weapon sounds; others would find it clutter. I understand that distinction is not personally of interest to you. For now, a fourth category is just theoretical, not a 2.12 item. I'm just asking for a different description of the existing category, other than "effects", that we can both live with. Something that sounds more human. How about "expressions"? If we can agree on a term, then I will revise the appropriate barks to use it.

I like the widget, but I'd love it to be an optional thing, toggled on/off by setting and/or CVar.

Sure, and a similar mechanism, not yet existing, could load translated subtitles, for Polish, Czech, etc. Sounds like 2.13+ to me. That is the main use case at this time. My own desire is not to limit it to that.

Hmm, interesting. The _12 version appears to be picked up at textscale of 0.15 or lower. So you'd have to get down to appx 7 pt type to start using the _12 as source, given my understanding that textscale 1.0 = 48 pts. Kinda baffling.

Yeah, I tried to do that sparingly. It's that low-hearing/audio-off vs normal-hearing/audio-on tradeoff again. Mostly did it when the text itself could be interpreted differently depending on tone. Like sarcasm. Current mechanism would make that hard to add as an option.

I know we disagree on what an "effect" is. To me, it's a non-human sound. So an arrow hit, or a raven call. Primarily to benefit low-hearing players. I would be fine with having a fourth category, between speech and effect. Let's call it maybe "vocal sounds". Here would go the barks that contain zero words. So, snores, cries of pain, some mutters; barks currently translated as just "(sigh)" or "AAiiee" In the short term, if you just fully implement 3 categories, but rename the 3rd category as "vocal_sounds" (or "vocalizations" or whatever), so there would be a "verbosity vocal_sounds" in .subs, then I'd be willing to redo the barks subtitles to use that.

At least for bark subtitles, fast readability is important, because they shouldn't be on the screen much beyond the vocalization time, and for fast talkers, that's not real long. Of the existing fonts available, Carleton and Stone are the easiest to read quickly at a glance. If you were going to allow a different font for story subs, assuming they are generally articulated at a more leisurely pace, then you could consider a more "themed" font. Still, a lot of TDM fonts are pretty slow to scan/parse.

I think this is probably "it depends". If a single AI is giving a story monologue, it may be implemented as a single .ogg file, just broken up into subtitles. So this would all be in the same slot. (Likewise, there are some long barks in a single .ogg file too). But the story could be in multiple .ogg files, delivered by one or several AI. Then, the slot could vary, if there also barks happening that scrambled things up. I could be wrong about this. I recall there was some chatter a long while ago about making what slot an particular AI uses somewhat sticky. That's interesting, about volume (or distance) threshold triggering of subtitle display. I'm guessing no threshold test is applied for story subs.

@stgatilov, I've been looking into the stray marks associated with Stone 12 pt. Not much progress, because there's something strange going on. Any change I make to the metadata in fonts/english/stone/fontimage_12.dat (whether in the core or as an FM "/fonts/" override) is ignored. Whereas changes to the corresponding 24 pt .dat (whether in core or override) do show up in the nominally 12 pt subtitles (with either gui textscale of 0.24 or 0.25). Is there something in the engine code that is keeping this 12 pt .dat from being used? There are no warning about such at startup. Perhaps some engine hack left over from when there was a missing file?

I think moving them to the FM-specific folder would be the right thing to do.

Be interesting to know if reloadDecls works on an edited core .subs but not on an edited FM-specific .subs

There's nothing about .subs or .srt files that says to me: these are decl files. So reloadDecls and reloadXData are equally arbitrary. On the other hand, "reloadSubtitles", yeah, that I would understand.

There's good news and bad news. The good news is that this zip file does indeed contain the missing dat file. I have checked that it is compatible with the existing dds file across printable chars* of the standard ASCII set. I see no reason not to include it with the 2.12 distribution. *except testing method using "inline" subtitles can't do double-quotes. And I didn't try whole set of Latin-1 chars. The bad news is that in doesn't solve any problems with stray pixels or poorly spaced characters, compared to scaling down from Stone 24pt. Artifacts were seen to the left of % C T W Y During test, characters were separated by two spaces, to isolate which char was causing an artifact. Nor did I see any visually discernible improvement or change in the rendering of characters. I was looking for any thickening of the thin parts of strokes, for instance. BTW, both Stone 24pt and now Stone 12 pt have weird stuff for ASCII "<" and ">". Maybe that's a TDM customization? The > replacement includes an artifact to right.

Just thoughts for possible futures. No problem.

True. Regarding this dynamic design, it could be argued that we should ignore the Acquired field (Inventory Pickup Message), since messages there are shown rarely, and not at all if the user turns it off. Instead, place the low subtitle slot just above the breath bar. Then all the subtitles slots would be lower. However, this would increase overlap with the corners, unless some mitigation was done. That could be done engine-side, if the slot-fill priority was changed to, e.g., middle-slot first, low-slot last. So the conflict-prone low-slot becomes rarely used. Other mitigating ideas - - move the Acquired field to the top, right under the Objectives Message field - do away with the Acquired field, and instead deliver its message using the subtitle mechanism (possibly with color markup or a different font than regular subtitles). This would require an engine enhancement, to generate a subtitle given a runtime-assembled string, without any sound file.

If no one turns up the missing file (previous post), then I'll probably try to figure out how to regenerate it sometime in 2024. And/or edit DDS images. But for TDM 2.13, not 2.12

I recall (from a year ago) I did try to go back as far as I easily could using TDM public resources. Also general searches on Google and Wayback Machine, for the specific filenames like "fontimage_12.dat" (in conjunction with "stone_0_12.dds") or possible alt naming like "stone_0_12.dat" Maybe someone with TDM SVN/Art Archive privs could get further into the past. Or who has a machine with Doom 3 loaded? It is also possible that file is present in one of the other Thief variants, possibly with a different filename. Someone else would be better placed to explore these possibilities.

To follow on. While the TDM distribution does have a DDS file for Stone 12pt: tdm_fonts01\dds\fonts\english\stone\stone_0_12.dds it is missing the corresponding DAT file: tdm_fonts01\fonts\english\stone\fontimage_12.dat so the system uses Stone 24pt as a basis instead. BTW, the Russian version has both files for Stone 12pt. If you try to use the Russian DAT (renamed) with the English DDS, pixel nightmare. I asked around in TDM a year ago if anyone had the missing dat file. No luck. Hmmm, didn't mean to highjack this thread. I'll shut up now.

Then the characters that you removed the pixels from would be less-well shaped. The right solution is to change the metadata around character spacings. That's deep in the weeds. And probably better pursued as part of generating a 12pt Stone image. If you want to take this on, I can send you some links. I did some prelim research on this last year, related to computing the width of a Stone string, but never tried to do a font edit or gen, because a lot of steps seemed unclear. EDIT: Some of my thinking here is that maybe the scaling down from the available 24pt Stone image to a desired 12pt is introducing artifacts. Also, backing off a bit from what I said above, maybe not removing pixels, but shifting any problematic character glyth sideways within an image, would fix things well enough. EDIT2: These are the main forum links I found helpful The "Stone Print" source font in ttf form is available, e.g., from www.fontpalace.com. Useful Doom 3 tutorials are #10 "Using custom fonts" & #11 "Editing fonts". Tools include "Export Font to Doom3 - v1.02" and Q3Font. Some of this stuff comes from the wayback machine of the internet archive. I can get you copies. Sorry, can't help much with DDS editing tools.

As designed, this should avoid overlap of the subtitles with the resizable central HUD elements: health bar, light gem, breathe bar, pickup message. It would not avoid all potential overlaps with the resizable corner elements.

This is based on the tdm_subtitles_message.gui given in the stgatilov's post you referenced, and also identically in 2.12 beta 3. I have reviewed this as you requested. I can't speak to the accuracy of the green bars in your screenshots, but the calculation seems correct. It derives from the calculation in mainmenu_settings_guisize.gui (of beta3), which finds the top edge of the bounding box of the Inventory Pickup Message (e.g., "Acquired 80 in Jewels"), then reduces that to account for the subtitle backing field height of 37, plus a 4 pixel gap between the lowest subtitle field and the pickup message. I also confirmed that the beta3 calculation of the top edge of Inventory PickupMessage is identical in both mainmenu_settings_guisize.gui and tdm_inv.gui; the latter is part of the HUD during game play.