Geep

Suppose we had a system like this: "verbosity story" are small width=0 by default "verbosity speech" are small width=1 by default The default of either can be overridden on a per-subtitle basis by using new option "-smallWidth" or "-sw", e.g.: with verbosity story inline "something.ogg" "I've hid the gem in m'lady's knickers." -sw 1 srt "something.ogg" "something.srt" -sw 1 // sw affects all messages of this srt the same with verbosity speech (as an alternative to breaking into individual messages and using srt) inline "yetmore.ogg" "I need to cast that spell tonight after midnight,\nbut once again, my supply of eye-of-newt is sadly depleted." -sw 0 #define FIELD_MARGIN is not anywhere official yet, just in my prototype tdm_subtitles_common.gui, hidden in yesterday's post. The values I show are from my analysis and testing, earlier reported in this thread and/or AI Barks.

When I create the bark subtitles, I limit each of the 2 lines to at most 42 characters. This will then work without problem (shown by analysis and QA) with a narrow field width given by left and right background field margins as follows. #define FIELD_MARGIN 160 The resulting field width of 320 is good with these uncompressed fonts: "carleton" with scale=0.25 (selects 12pt font) [current default] "stone" with scale=0.25 (selects and scales 24pt font) #define FIELD_MARGIN 200 The resulting field width of 240 is good with these compressed fonts: "carleton@aspect=16:9" with scale=0.25 (selects 12pt font) "stone@aspect=16:9" with scale=0.25 (selects and scales 24pt font)

When I posted my prototype image on Sept 22, I should have included the corresponding revised tdm_subtitles_common.gui code. For the record, here it is: @stgatilov, you've of course independently implemented your version. My version evolved from 2.11 and the testSubtitles... gui code, but with new more-extensive use of #defines. Like testSubtitles..., it uses a narrower field width that I MUCH PREFER. I know this is contentious, and that you and @datiswous evidently wish to retain the original wide field width. Can we compromise along these grounds: have the original field width for "verbosity story" have the narrow field width for "verbosity speech" subtitles (which I guarantee will fit with either of the two fonts we've been considering) "verbosity effects" TBD This compromise would have an advantage: the user could tell at a glance whether the clip is story (or briefing) versus a bark. The implementing .gui code would choose the right width, based on the global verbosity enumeration I've requested earlier.

Looks like it works reasonably intuitively. My original conception was distance-to-alpha (as you have here) rather than volume-to-alpha, anyway. Interesting your version makes the disk interior translucent, rather than transparent like my version. May be the way to go. You're art's pretty reasonable, but I'll take a look at it further when I get back to my dev machine in a week, if you can push your change out. Also, please, include that verbosity enumeration global too. Going offline for a while.

Mostly yes. For those subtitle sets I've released so far, the remaining steps for someone (not me) are - - optionally do a second QA pass. (I've tried to be careful and thorough, of course.) - fold them into the 2.12dev distribution. This mainly involves deciding where the subtitles for each voice should live when distributed and copying the .subs and .srt files there. It may also involve editing the .subs file to change paths accordingly. That edit is just a find/replace-all, so easy. There are additional gui presentation issues, which are (I hope) unlikely to affect the foregoing. About those issues: experimentation and discussion are on-going, and ideally may be resolved before the final 2.12 release. Also, regarding barks emitted by the player and by non-human AI... unclear to me how they should be categorized ("verbosity speech" vs "verbosity effects" vs ignore). In any event, I don't expect to get to them in a 2.12 timeframe. BTW, I'll be traveling this coming week as well as later in the month, so will be periodically unresponsive.

The subtitles for The Commander vocal set is now available for eventual incorporation into TMD: testSubtitlesCommander.pk4 "Vocal Script: Commander" indicates that he "is used to leading other people. He is confident and used to being listened to. He talks a lot about plans and organization." The script has a number of evocative lines specifically for mage and merchant characters. Statistics In file fm_root.subs there are 298 inlines, including: 57 with an explicit linebreak, intending 2 lines 241 without Of these, 13 have explicit duration extensions, as follows: 8 from 0.25 to 0.49, for 17 cps 5 capped at 0.50 seconds, for 17-20 cps There are 22 SRTs, made up of: 18 with 2 messages* 4 with 3 messages *Two of these were vocalized tunes with a 2-second start message and later 2-second end message. Of the 48 total SRT messages, there are: 18 with an explicit linebreak, intending 2 lines 30 without In all, there are 320 voice clips with subtitles, showing 346 messages. Corresponding Excel File SubtitlesCommander.xlsx As usual, this is based on Version 5 of the Excel Template for TDM bark subtitles.

BTW, this prototype is based on 2.11 gui script, so is functional. All the ovals show and hide in concert with their respective subtitles. The only thing (besides what I mentioned in the above post) that's not yet coded is the special case of dot hiding when dot_x == 0 and dot_y == 0. I can think of several ways to do that, so shouldn't be a problem. I plan to redraw that oval in a larger .tga, so it will look smoother when presented in the size shown.

@stgatilov, attached is a screen shot of what I'm calling the "sound source cue" or "sound source oval" directional indicator. Unlike the previous Photoshopped mockup, this is implemented as a prototype in gui script. It shows a cropped screenshot of the 3 stacked subtitle slots, with a red dot indicating the direction, respectively (from the bottom slot) left of player, straight in front of player, and straight behind player. Those locations are simply hard-coded by local float variables dot0_x, dot0_y, dot1_x, dot1_y, dot2_x, dot2_y. I need the engine to supply those as gui globals instead. (You can change the names as you wish). Once I have a 2.12dev update with those variables (and please, the verbosity enumeration too, that we talked about), then I'll do another pass to optimize the art and tweak the dot positioning and size. That's better done when dynamic dot movement is available. For the next go around, it might be sufficient if the engine just provided the direction as a unit vector, in which case the engine-side assert is: square_root(dot_x^^2 + dot_y^^2) = 1.0 Later, we could play around and see about encoding distance too. In which case the "=" in that assertion would be replaced by "<=". Do you think that "sound source cue" should be something the user can turn on or off as an option? If so, that's another gui global to pass, probably a cvar.

I didn't think of this in the mockup image, but it would probably would be good to put a white dot at the disk center, representing the player position.

Not a fan of elevation... just makes direction harder to understand at a glance. I was thinking of just showing direction, not distance, on my proposed disk. If you passed X and Y coordinates unnormalized, I might have to take square roots in gui-script, which could be hard. I am unclear if we can meaningfully show distance at a glance as well on the disk. But open to experimenting with that as well.... In which case, the location dot would not be constrained to the perimeter, but could move towards the disk center point representing the player location. The radial distance (talking here about the disk viewed untilted) to the dot could be passed as a scaled vector, where x and y are each in the range 0 to 1. How best to scale that distance on the engine side? Could be logarithmic instead of linear. A radius of 1 would be the most far distance that sound could travel. A radius 0.1 or 0.2 would be right next to the player. Don't want to make it too close to the player dot, because it loses granularity of the perceived directional cue. Also, maybe (0,0) would indicate a special-case ambient/global sound, or player voice? Alternatively for representing a sound "next to player", the engine could pass a very low value (e.g., 0.01 radius), but the gui script would apply a minimum threshold like 0.1 or 0.2

@datiswous, as to where to place linebreaks, I found the "Line Division" section of this webpage to be useful guidance: https://dcmp.org/learn/597-captioning-key---text (For my Style Guide Part 2 - planned for year-end release - I have a very similar section, just with the subtitle examples changed to use typical TDM barks and centered justification.)

The subtitles for The Moor vocal set is now available for eventual incorporation into TDM: testSubtitlesMoor.pk4 "Vocal Script: Moor" describes him as "a foreign soldier from the south. He is a man of few words, fluent in English but with a strong (Nigerian) accent. He occasionally uses awkward phrases, and is as liable to communicate with a grunt or single word if that will do. He is tough, stern, and reserved, not given to a great deal of emotion." While not spelled out in the original vocal script, the accent/dialect performed had words that start with "th" (e.g.,"there, that") pronounced as "d" (e.g., "dere, dat"). This is what linguists call "th-stopping". Serious consideration was given to rendering the subtitles that way for flavor, but ultimately the original standard spellings were kept for ease of understanding. Statistics In file fm_root.subs there are 221 inlines, including: - 12 with an explicit linebreak, intending 2 lines - 209 without Of these, 15 were given explicit duration extensions, as follows: - 12 from 0.25 to 0.49, for 17 cps - 3 capped at 0.50 seconds, for 17-20 cps There are 3 SRTs, each with 2 messages apiece. Two of these were "tune hums" with a 2-second start message and later 2-second end message. The remainding SRT, with two sentences of text, could have just fit into an inline, but manual-word-wrapping within the second sentence would be poorly placed. With SRT, each sentence got its own message, and the manual linebreak in the seconds sentence was at a reasonable place. In all, for this voice, there are 224 voice clips with subtitles, showing 227 messages. Corresponding Excel File SubtitlesMoor.xlsx This is based, as usual, on Version 5 of the Excel Template for TDM bark subtitles.

"...small mistakes ... which then take a while to figure out" sounds like the human game plan.

You have to use backslash "\" to escape special characters, not forward slash "/"

??? I've been doing this, oh, forever, without a problem. Typical example line in fm_root.subs: inline "sound/voices/lady/tdm_ai_lady_alertdown_to_idle01.ogg" "I must have let my imagination\nget the better of me."

As for implementation: Let's say the engine generated a sound source location (relative to the listener's axis, and only in the horizontal plane) as a unit vector in Cartesian coordinates. That is, the origin is at 0,0 and straight ahead is 0,1 straight behind is 0,-1 due left is -1,0 due right is 1,0 This would be passed to the gui as floats, e.g., soundDirN_x, soundDirN_y, where N is the subtitle slot number. The gui would take care of translating the origin and scaling the vector. For the oval, the scale factor would be different in the x and y directions. (This is an approximation of actual location on the perspective projection of a tilted circle, but should be good enough. And avoids any trig functions on the gui side)

@stgatilov, I was originally thinking I could take your 5 values and, in the gui, do the inverse math to get back what you called in the engine code the "spatializedDirection" (normalized x,y vector from the listener to the source, relative to the listener's axis). But I realize that's impractical... math would need C++ Instead, let me show the end goal I was thinking about, through a mockup. The idea is to have a non-moving oval (representing a disc laid flat on the floor, in perspective), with a small colored square constrained to move smoothly along it, representing the direction of the sound source. In the mockup (attached cropped image), the oval is blue, the square is red, and the direction being indicated is front right. (Or maybe the ring should be dark red and the square light blue... or disk could be solid, etc.) The translucent field is 240 (out of 640) pixels wide, so the oval shown is roughly 30 pixels wide. The perspective could also be made more prominent, if instead of a uniform stroke width on the ring, the lower ("nearer") edge was thicker than the upper ("farther") edge. If implemented, the gui spacing between the 3 subtitle slots (not shown here) might have to be tweaked a bit to avoid overlaps.

FONT NOTE: Starting with this test FM, to improve readability, the Carleton subtitle is compressed in width to 75% of its size in previous test FMs. The backing field is similarly reduced in width. These are implemented in the FM's custom-override guis/tdm_subtitles_common.gui. If desired, you may copy that file to previous test FMs to propagate the change. The subtitles for The Lady (aka Noblewoman) vocal set are now available: testSubtitlesLady.pk4 The wiki's "Vocal script: Lady" suggests these traits: As usual, the testing FM serves as the vehicle to provide these subtitles for eventual incorporation into TDM. Statistics In file fm_root.subs there are 243 "inline" subtitles, including: 37 with an explicit linebreak, intending 2 lines 206 without 17 of the inlines have explicit duration extensions, as follows: 11 from 0.25 to 0.49, for 17 cps presentation rate 6 capped at 0.50 seconds, for 17-20 cps none with more than 0.50 seconds There are 2 SRTs, each with 2 messages that respectively indicate start and end of singing/humming. No duration extension was needed, and none of the 4 messages contained a linebreak. In all, in this vocal set captioning, there are 245 voice clips with subtitles, showing 247 messages. Corresponding Excel File LadySubtitles.xlsx This is based on Version 5 of the Excel Template for TDM bark subtitles, which was also featured in the preceding work for Average Jack, The Pro, The Maiden, The Grumbler, and The Mature Builder.

Probably the right way to fix Stone artifacting would be to provide the two missing 12-point files - stone/english/fontimage_12.dat stone/russian/fontimage_12.dat I gather, from the wiki's "Font Conversion & Repair", to do this, you'd - start with the ttf (formally, for the "Stone Print" font, available from, e.g., fontpalace) use some version of ExportFontToDoom3 to generate the two .dat files extensively test and tweak with font_patcher and q3font maybe some monkeying with .tga and .dds I didn't follow. I'm not going to attempt this myself (at least not this year). Maybe there's some experienced font hacker around?

FYI. Just redid the stat analysis, assuming that the engine, after dividing Stone 24pt font width by 2 to get 12pt, then rounds up. In that case, the Stone string is still less wide than Carleton, but now only 4-5% less, instead of 7-8%.

@stgatilov, both the compressed Carleton and Stone fonts look better than the original uncompressed IMHO. We could give the user a choice of either, while keeping the gui scale factor fixed at 0.25 (e.g., 12 pt). If Stone's artifacting you mentioned was not too problematic. I did a statistical analysis of those two fonts, and Stone strings seemed to be slightly less wide than Carleton by about 7% (however, Stone 24pt requires scaling down to get to 12pt, and the analysis may not be treating the resulting "half-pixel" widths right.) But if true, background field widths based on Carleton should still be excellent for Stone. Another topic. I'd like to play around a bit with the 5 sound-source-location variables you were using to position the white bars. In file tdm_subtitles_message.gui, these were of form: "gui::subtitle0_oriBackLeft" // where 0 if subtitle was shown in vertical "slot 0"; could be 1 or 2 and name suffixes were _oriFront, _oriFrontLeft, _oriFrontRight, _oriBackLeft, and _oriBackRight Could you briefly explain what values these could take on, how they would work or differ, how often they get updated? Thanks

A "Style Guide" for how I have been doing the bark captioning has been percolating on my desktop for some time. In order to move it along, I have split it into 2 parts, and the first part is now available as a Word doc here: Subtitle Style Guide - Part 1 Part 2, the remainder, with more supplementary material, hopefully will be available around year's end.

@stgatilov, I earlier read your 6283 description about 'So e.g. we can support fonts like "fonts/carleton@aspect=16:9" ', but I thought that meant there was a pre-created font variant with filename "carelton@aspect=16:9" to be distributed. But maybe "@aspect=16:9" is a gui keyword to trigger on-the-fly compression? [Duh, I guess I could just try that directly, but not at moment.] Yeah, I agree it's more confusing than helpful, and probably should be dropped. I'm sorry I suggested it (at least the idea of indicating location by a perimeter light; maybe not indicating volume too). I don't have a better idea at the moment. It would be interesting to play around with visually distinguishing "story" from "speech" subtitles. Lots of ways to do that, but having the enumeration available is the prerequisite.

@stgatilov, would it be correct to say that the latest public 2.12dev contains the original 4:3 fonts, and does not distribute the narrowed 16:9 fonts (e.g., for Carleton and possibly Stone)? Also, I'd greatly appreciate it if you could expose a numeric variable whose value is set to indicate whether the current subtitle is of type "verbosity story", "verbosity speech", or "verbosity effect", that can be read (but not set) in tdm_subtitles_common.gui

Added that to the trigger_sequencer synopsis on the Triggers wiki page.