Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Geep

  1. 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.
  2. 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.
  3. 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"
  4. 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.
  5. 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?
  6. 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
  7. 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.
  8. 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?
  9. 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
  10. @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.
  11. 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.
  12. 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.
  13. 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.
  14. @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):
  15. 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.
  16. I noticed that too. There is a bit of intentional padding on the right hand side, but this seems too much.
  17. Yes, the backing field shown, while narrower, is still a fixed width for all bark texts, so still wider than ideal for that particular phrase. The width is the minimum needed to safely accommodate subtitle lines up to 42 characters long of 12 pt Stone font.
  18. So true. In that regard, gui code has been available for a few months to create a narrower backing field for barks (i.e., speech verbosity) than for story text. This code has not been included in the beta to date. Perhaps it will take users in addition to me to favor and push for it! If you want to try it, put this code in your FM's "guis" folder as over-ride file "tdm_subtitles_message.gui":
  19. Ah, I see now. The bordercolor code in the gui is just a remnant around the now-transparent backing field.
  20. True. It would require a modification of the engine code. Earlier this year I wrote two experimental C++ utility programs that do the required calculation, for respectively 12 pt Carleton and (scaled to 12 pt) Stone fonts. However, others have expressed distaste, on complexity grounds, to having variable-width backing fields, so I've since been restricting my advocacy to a narrower fixed-width backing field for speech-verbosity subtitles. This outlining isn't really visible in your screen shots; and I'd like to see various color-tone game locations too. I see you use the "bordercolor" attribute for your outlining. I vaguely recall there was some circa-2010 TDM "drop shadow" experiments with (I'm guessing) using this for subtitling, with the Carleton font then in use. (This was before I got involved in subtitling.) Same conclusion: a bit problematic with the given font. So that led to the translucent backing field as an reasonable approach. It would be possible to add a new unicolor font just for subtitles to TDM. There is a roadmap for this, but it's a major project, so TDM 2.13? Agreed. That was part of my motivation for wishing to narrow the width of the backing field. I'm in favor of having settings to let players have more flexibility in the subtitle presentation. That would include font color.
  21. Just too small a gap currently between blocks, to not overlap with something. I think it's better to overlap with the subtitle it's associated with, rather than the one above. The gap could be enlarged, but then 3rd topmost block would be close to screen center vertically, blocking more of the general view. Oval could be further shrunk, but becomes less informative. I guess, with tricky programming, you could suppress the ovals when there are more than 1 blocks shown. Probably no perfect answer.
  22. After you do that, check to see if the now-white ring visually interferes with the white caption font. If so, the ring might need overall thinning. if not, good to go.
  23. Thanks so much. I'll review the spreadsheet starting tomorrow and after any tweaks, export to .subs as inline. Then convert any to srt that need it, and do QA. The usual process, tho possibly a bit slow due to travel/holidays. I've already built a testSubtitlesDrunk to house the subtitles.
  24. The subtitles of The Lady02 vocal set is now available for eventual incorporation into TDM: testSubtitlesLady02.pk4 Lady02 is another noblewoman, somewhat newer and so unmentioned on the wiki. She is a drawling speaker, often indecisive, and given to long musings. Favorite topics are how boring life is for the wealthy, and how to keep men of the household and the maids apart. Lady02 required heavier and more complex use of .srt files than most AI characters, due to: Her slow, rambling monologues Some of the underlying .ogg files were poorly trimmed at the end, so needed compensatory .srt timings. I appreciate the assistance of @datiswous in this effort. Statistics In file fm_root.subs there are 195 inlines, including: 25 with an explicit linebreak, intending 2 lines 170 without Only 1 of these needed an explicit duration extension, to the capped value 0.50 seconds, for 17-20 cps There are 116 SRTs, including: 78 with 1 message (to correct trim problem) 24 with 2 messages 7 with 3 messages 2 with 4 messages 3 with 5 messages 1 with 8 messages 1 with 9 messages Of the 187 total SRT messages, there are: 90 with an explicit linebreak, intending 2 lines 97 without In all, there are 311 voice clips with subtitles, showing 382 messages. Corresponding Excel File Lady02Subtitles.xlsx This is based on Version 6 of the Excel Template for TDM bark subtitles.
  25. I suppose you could split the difference, making the line moderately thin but obvious at the lower edge but vanish at the upper edge, letting the gray interior carry the upper shape. So, I prefer the 3D slope, but am OK without, if that's what others like.
  • Create New...