Geep

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?

So maybe new CVars along the lines of the following would do the job for 2.12: subtitleColorR 0.00-1.00 subtitleColorG ditto subtitleColorB ditto subtitleBackground 1/0 subtitleSoundSource 1/0

@snatcher, I meant to mention, I do like your sector sound-source widget. I'd be happy going with that. As to its ring color.... while my personal pref tends toward some color that would contrast with text color, I guess most folks would prefer white, to match the current text color (and likely default if text color is made variable). That would be fine.

I reviewed the Stone font spacing vis a vis padding: Worst-case spacing for Stone 24pt for ASCII lower-case characters = 20 (and "A" is less than this) Scale by 50% to 12 pt = 10 Compress-width of font by 0.75 = 7.5 So I'm thinking a reduced right padding, now 7.5 px, plus a new left padding of 7.5 px to improve centering.

I wonder if you could test 9x versus 4x-diagonals and 4x-non-diagonals? Maybe the extra 5 renders don't add much. There probably is some minor performance effect. I think you're still showing the widget too high, so it seems to be associated with the wrong subtitle. I prefer @stgatilov's original vertical positioning, even though it pushes the widget's lower edge against the top of the caption lettering. I wasn't sure what you where trying to point out as a problem... was it the word wrap? Yeah, the automatic word wrap with centered text can look ugly at times. An FM author can choose to insert a manual line break in that case. I do that routinely all the time for barks. Since padding is part of the background box, sure. It occurs to me now that maybe, to improve the appearance of text centering, the background box should also have equal-size padding on the left. That is, the location and size of the inner box is unchanged, but the outer box is wider and its origin shifted left, so the inner box is centered horizontally within. The padding can certainly be made smaller. I imagine the seed value of 17px was for a worse-case character like "W", that was then rounded up to 20. We could shrink it by: - choosing the seed character as the widest that might actually be at the end of a line followed by space to cause word wrap. Probably "w" or "A". - not rounding up - scaling by the compression aspect ratio I'll try to come up with a new number. No problem here with having the background by default. But recognize there's a compromise between world visibility and text readability. Can't we make it possible to turn the background off for people who hate it so much that they avoid using subtitles because of it? "...visible in all circumstances" may be too high a bar. The simple implementation would be a single CVar that toggles the background on/off and possibly, conversely toggles fake drop shadows off/on.

I will take a look this coming week. In my heart of hearts, I'd rather make "background or not" a user choice. The simple version of that wouldn't be too hard: just a CVar settng the backing field visibility. The more sophisticated version, where no-background implies fake-drop-shadows, requires more thought to make it live with the backing field code.

@snatcher, based on your earlier sample, I see that the horizontal widget positioning in the beta release of tdm_subtitles_message.gui and in my version were both off by 10px to the left. (Probably because the widget was originally wider.) My version corrected here (but not addressing text centering problem):

There's the inner box to constrain the text, and trigger word wrap, and the outer box to show the backing field. These are identical in size and location except the latter is a bit wider, by 20 px. A comment in the .gui code says: // #5914: engine allows overflowing textbox size by one character // maximum character width is 17 at textscale 0.25, so leave horizontal padding 20 on the right So the motivation is to keep the text from never visually exceeding the backing field. However, that extra padding can not be considered when the engine decides the point about which to center text in the inner box Probably a padding of 20 is excessive, even more so now that a width-compressed font is used. That said, there may be something else dominating the anomaly. And the sound location widget is also off-center.

I noticed that too. There is a bit of intentional padding on the right hand side, but this seems too much.