Geep

Here is the final release of The Wench, with Dragofer's Dec 9, 2023 sound file revisions (see bugtracker 6284), as included in TDM 2.12 beta3: testSubtitlesWenchFinal.pk4 The revisions correct a few mismatches between what was said and what the intended purpose was. The statistics are little changed. The testSubtitlesWenchFinal FM will run under beta 3, with the same GUI as testSubtitlesCynic. Details of Revisions There were no changes to the collection of .srt files. The changes affect only the .subs file (and what's in testSubtitlesWenchFinal's FM-specific sound shader). It is too much effort and time to revise the Excel spreadsheet, of early "v1" barks template form. Instead, if the reader wishes to do so, start with the WenchOriginalSubtitles.xlsx (available via the original Wench post), and apply the changes below. The total number of rows is unchanged.

@stgatilov, I likewise think that the chosen source image would be the same for 0.24 and 025. In the case of Stone, that would the 24pt (corresponding to 0.50 textscale), since no 12pt source image is available. And agree that scale factors of 0.24 and 0.25 should render character sizes slightly differently. As long as it was purposeful, even at the potential cost of minor blur, that's fine. As you imply, such blur may be unavoidable anyway, since the otherwise-desirable aspect compression would also inflict it. Just need to think of the 0.24 scale results as 11.5 point size instead of 12.

The subtitles of The Cynic (aka Bernie) vocal set, are now available for eventual incorporation into TDM: testSubtitlesCynic.pk4 This male character is often snide or crabby. In addition to general barks, there are phrases for a guard of the city watch, and for a trader. Note for Integrators This release incorporates and supercedes the TDM 2.10 subtitle demo, provided by @Dragofer, with its version of tdm_ai_cynic.subs. Likewise, it obviates the need for the distribution's fm_test_subtitles_ai_cynic_dragofers_dozen.shdshd Statistics In file fm_root.subs there are 301 inlines, including: 40 with an explicit linebreak, intending 2 lines 261 without 23 of these have explicit duration extensions, as follows: 16 from 0.25 to 0.49, for 17 cps 7 capped at 0.50 seconds, for 17-20 cps none with more than 0.50 seconds, for 20 cps There are 12 SRTs, including: 10 with 2 messages 1 with 3 messages 1 with 4 messages Of the 27 total SRT messages, there are: 17 with an explicit linebreak, intending 2 lines 10 without In all, there are 313 voice clips with subtitles, showing 328 messages. Corresponding Excel File TheCynicSubtitles.xlsx This is based on Version 6 of the Excel Template for TDM bark subtitles. The "Script Subtitle" column contains Dragofer's original subtitles. About the GUI Like The Drunk, subtitle backing fields for The Cynic uses the "tabbed widget" design, with reduced main field heights, one of several design alternatives that were being discussed. For the sound source widget itself, it uses snatcher's white sector oval provided by beta3.

Likewise in subtitles; the "T" has a similar artifact. The implementation of the Stone font has known glitches, including poor spacing of "J". Probably made worse by the fact that no 12pt Stone is currently available, only 24pt and 48pt. So what you see is scaled down from 24pt. The images for the text characters are in a grid within a single .tga file (for a given base font size). Stray pixels come from adjoining letters in the grid. IMHO, it is possible to overcome such shortcomings, but not quick and easy. A good project for 2024 and TDM 2.13

I believe the subtitle Stone font is currently scaled to 11.52 pts, instead of 12 pts. I have asked before whether that is the intended scaling, or inadvertent, but heard nothing. In tdm_subtitles_common.gui, there is: #define SUBTITLES_TEXT_SCALE 0.24 In TDM 2.11, it was: #define SUBTITLES_TEXT_SCALE 0.25 Where a scale of 1.0 represents 48 pts.

About Errors Running Recently-Created testSubtitles... FMs under TDM 2.12 Beta 3 Console gui parsing errors now occur in the FM's custom version of tdm_subtitles_message.gui, because Beta 3 no longer defines SUBTITLES_TEXT_BORDERCOLOR. To correct this, in the testSubtitles.../guis/tdm_subtitles_message.gui, comment out the 2 lines that say: bordercolor SUBTITLES_TEXT_BORDERCOLOR Or replace with the so-fixed and updated version of this file from testSubtitlesCynic, to be released shortly. Early testSubtitles... FMs created during the first half of 2023 may need additional surgery to run without error.

Let me know when the sound file renamings done by Dragofer for bug tracker 6284 are incorporated into the beta release. (This may have already happened, dunno.) Then I'll revisit the Wench subs. EDIT: @nbohr1more, I see beta3 has updated Wench sound files with modification dates of Dec. 7, 2023. So I'll take it from there.

Dunno. I always assumed not. So for my testSubtitles... FMs, I adopted a QA workflow to make corrections in large batches, so the restart was needed less often.

I am willing to take a look at it, but not before sometime next week. Working on the last vocal set, for the Cynic, first.

Not technically, no. snatcher, maybe it's soon time for a subtitle Modpack to offer some of the design alternatives.

It appears it's only affecting the vertical positioning of the subtitle slot stack, so I wouldn't think it affects max chars per slot

Sadly, I'm not optimistic about ever seeing subtitle accommodations based on HUD preferences, or on user choices. Given all the dust that's been kicked in my face for wanting just auto-selected two-width subtitle boxes, even as a user option.

I would prefer the tab, just because it shows more of the world unimpeded, and that unimpeded zone provides a wider vertical gap between stacked subtitles. But I could live with the alternatives: a tall background; or a ring that partially pokes above the background. But... Good question. I'm ready to fully abandon backgrounds, just because they are such a source of conflicting visions. As to how thick the outline should be, I don't think the potential for very rare color markup should be a deciding factor.

I didn't research The Black Mage, but presumably the speech of the guy in red is being delivered by a method where the source location could not be located. This might be because it was tagged as by narrator or by player. Or maybe triggered by a script somehow, directly or via a speaker. Not sure about that last thing, because a speaker does have a location (whether it's the "right" one from the story point of view is another matter.) Might warrant further investigation within the source code.

Yeah, I'm surprised the bolded (well, fattened by outlining) text is even still readable.

Your latest design is OK, but doesn't touch on several aspects that I addressed in my design: ring lower edge no longer crushing the top of 1st line text excess backing field below text 2nd line trimmed, to allow space for (1) backing field behind ring, as I believe requested by snatcher & datiswous I could further discuss this and the narrowing issue, where views differ, but I'm more than OK to "switch from background boxes to outline around text", as you suggest. There is still leaves improvements to ring vertical spacing - a la (1) - and not have the ring interior be transparent (probably just opaque) - similar in spirit to (3). And of course, actually implementing it in the beta. snatcher found 8-fold to be visually best. The minor artifacting with the scaled Stone font (e.g, a wisp to the left of a capital T) will become more prominent with drop shadows. But that could be addressed in a font update to include native Stone 12pt in 2.13

Ah, got it. Thanks. Corrected version:

The subtitles of The Drunk vocal set, with the assistance of MirceaKitsune, are now available for eventual incorporation into TDM: testSubtitlesDrunk.pk4 This male alcoholic character has a rough, gravelly voice, slow and sometimes a bit slurred or halting. Besides general barks, there are utterances as a guard of the city watch. Statistics In file fm_root.subs there are 405 inlines, including: - 59 with an explicit linebreak, intending 2 lines - 346 without Of these, only 1 needs an explicit duration extension (in the range 0.25-0.49, for 17 cps). There are 32 SRTs, including: - 27 with 2 messages - 5 with 3 messages Of the 69 total SRT messages, there are: - 23 with an explicit linebreak, intending 2 lines - 46 without In all, there are 437 voice clips with subtitles, showing 474 messages. Corresponding Excel File TheDrunkSubtitles.xlsx This is based on Version 6 of the Excel Template for TDM bark subtitles. Change to GUI New features of testSubtitlesDrunk to advance TDM 2.12beta: The oval ring showing sound source direction is now in a raised tab above the caption backing field (and matching it). That field is not as tall as it used to be, being somewhat tighter around the caption text vertically. The ring, with snatcher's sector design, and its red dot are also positioned better.

I have been quite careful to ensure that making the subtitles narrower for barks (but not story verbosity) is not potentially breaking. Examples of this treatment have been included in all my more recent testSubtitles... releases. Yes, this is "crucial" for me. Regarding the padding issue, to restate: TDM 2.11 and on through the 2.12 released beta version use a subtitle right text padding of 20 px. While some padding is necessary, this does a poor job of centering the text visually in the backing field. This is obvious with a short bark. My redo of this, with padding of 7.5px on both sides, fixes it, while I believe not causing any problems for word wrap of subtitles with the given compressed font & scale. I'm provided several versions above of this fix (code hidden as Spoiler). Most recently, this was with snatcher's suggested tabbed location ring and vertically-tighter backing field, here This version will also be incorporated into testSubtitlesDrunk, to be released tomorrow just released. I would urge you to incorporate this code (or a close variant) into the next beta release.

I dunno, it seems to me that if you're not going to show the ring widget (because, say, it's the narrator talking, so second parameter SUBTITLE_SPATIALIZED is false), you shouldn't show the tab it sits on either. About the red dot location. I understand what you are saying about perspective earlier, but that might have been more apt when the ring had a thicker lower edge. As it is, I tested by first facing the sound source, then turning 180 degrees. I expect the red dot to be about the same distance from the ring perimeter... that's why I tweaked by 0.5 px Hmm, maybe we should at least try to get subtitle font color among the possible CVars. That is probably the least controversial. I see the choice as either to be fully flexible (triplet for RGB) or, easier for the user, just a boolean (white vs yellow). Either would work for me. You guys? BTW, it is possible to markup particular words in the subtitle with a primary color, for emphasis. @datiswous, you asked about this a while ago. Did you actually apply it to any game FM? The 2 obvious colors for emphasis are red and yellow. A yellow emphasis would be lost if all the text was yellow. Another potential problem: if the fake drop shadows were an option, then the markup would also override the black shadow with color, leading to the emphasized word becoming an unreadable blob. (This could be resolved by the engine providing a second version of the text string, stripped of markup.) Otherwise, maybe a policy for subtitlers: "no markup on subtitles"

Um, maybe the dot in the center is just not fully opaque in its center. Anyway, here's the latest version. Also, the location of the red dot may have been off by 0.5px vertically in the previous versions (and maybe the beta?). Fixed.

I gather you're looking to shorten the backing fields, to improve world viewing. Reasonable. Certainly I could put a translucent box behind the widget, much as you have shown. Except, for reasons discussed above, I can't spare that many pixels vertically. So the widget top edge would be at the box top edge, and the widget bottom edge would still be close to the top of the text chars. Probably a tight fit on the sides would look better in that case. EDIT: Maybe the widget can jut more into the gap between fields, so a few pixels can be stolen. I don't think I can get the gui itself to draw a translucent background in an oval, instead of a rectangle. The widget image itself could have a translucent background within the oval, but it would be hard to match alpha'ing with the text backing field. Alternatively, as mentioned before, you could forgo a widget background and just have an opaque widget interior. Maybe 2 shades of gray to denote the sector. BTW, I noticed your white widget had a yellow center dot. Was that on purpose, or just an artifact of making a yellow version?

I could move the text down 1 pixel more, but then the text descenders don't have much to breathe. The overall problem is that the bottom-most subtitle slot, if moved further down, begins to conflict too much with other HUD items. For wider story subtitles, this is the corner inventory and weapon items. For all subtitle types, it is the lower informational messages that can appear above the breathe bar. Keep in mind that all these conflicting HUD elements can be enlarged at user discretion through Settings. One solution is to have the engine change the order in which it fills empty subtitle slots. Currently it is: 0 (lowest), 1, 2. If instead it did either of these policies: Fill order: 1, 2, 0 for all subtitle types; or Fill order: 1, 2, 0 for story subtitles. 0, 1, 2 for non-story subtitles Then the frequency of conflict would be significantly lessened - particularly with (1) - since having 3 subtitles shown at the same time is rare. With a revised policy, the backing fields could be made taller, allowing more widget room, with slot 0 (and slot 1 to a lesser extend) lowered

In this next version, the vertical height of the backing field is 1px taller (at the expense of gap space below each field), and the text and widget are vertically repositioned within it.

For the record, here is another version of tdm_subtitles_message.gui and the standard backing field, now improved with the right horizontal padding reduced to 7.5 px, and a new left padding to match, for better visual text centering. I also removed a comment about a possible CVar subtitle_narrowfield_nonstory, which seems less important than the other potential CVars. Beyond that, as you guys have noted, vertical dimensions could be adjusted to improve the appearance of the widgets. I'll try to come up with something concrete next, keeping conflicts with other adjustable-size HUD elements in mind. Another question for you: To cover a case where the backing field is suppressed, should the sector widget interior still be largely transparent, or would translucent or opaque be better?