Subtitles - Possibilities Beyond 2.11

[Geep]

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?

[Geep]

@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.

Edited September 5, 2023 by Geep

[Geep]

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)

[datiswous]

On 2/27/2023 at 11:51 PM, Geep said:

For inline, you just embed a "\n" to get 2 lines.

This does not work. Just tested.

[Geep]

6 hours ago, datiswous said:

This does not work. Just tested.

??? 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."

[datiswous]

I tried it and it didn't work. Maybe I shouldn't use spaces?

So:

I want /n to dig treasure.

Doesn't work, but:

I want/nto dig treasure.

does?

[Geep]

1 hour ago, datiswous said:

I want/nto dig treasure.

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

[datiswous]

hm.. I wonder if that's what I did.. Would be kind of a stupid mistake. But I often make small mistakes while creating subtitle files, which then take a while to figure out.

[Geep]

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

[datiswous]

On 9/11/2023 at 5:21 PM, Geep said:

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

Ok, yeah this was why it didn't work.. Got it working.

I don't think I ever used linebreaks in subs, maybe I should start implementing them for nicer look.

[Geep]

@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.)

[stgatilov]

On 9/4/2023 at 12:10 AM, Geep said:

@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 guess at this moment we have too many analysis and need "the decision"

Maybe I'd share the GUI code for

And we'll just accept it or decide what needs to be changed?

 

Quote

 

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

 

The code is here: https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/ui/UserInterface.cpp
Check SubtitleOrientationProbeVars, ComputeSubtitleProbeValues, basically everything about subtitles and probes.

The source for spatializedDirection is in https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/sound/snd_world.cpp  (just search for spatializedDirection ).

So I think right now the XY plane in listener's local coordinates is considered.
5 virtual speakers are placed. Then we look at the unit direction vector to sound source (distance does not matter), and decompose it as linear combination to two adjacent speakers. The coefficients are put into these "oriXxxYyy" GUI vars. As far as I understand, this approach is used to compute volumes for individual speakers on 5.1 sound systems.
Volume affects alpha-transparency (_alpha), but I think it is not very reliable now.

[stgatilov]

On 9/5/2023 at 7:43 PM, Geep said:

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.

Yes, it sounds like better idea than virtual 5-speakers.
I guess simply passing local X and Y coordinates would be enough for this.

Do we want to show elevation somehow?

[Geep]

22 hours ago, stgatilov said:

I guess simply passing local X and Y coordinates would be enough for this.

Do we want to show elevation somehow?

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

[Geep]

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.

[Geep]

@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.

[Geep]

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]

On 9/22/2023 at 6:24 PM, Geep said:

@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.

I have implemented your idea:

The volume-to-alpha thing is a bit weird since it does not take volume of the sample into account (hopefully improved in the future). And perhaps someone would replace images (I'm not an artist, you know).

But it works and looks nice

[datiswous]

This is pretty awesome!

[Geep]

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.

[Geep]

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:

Spoiler

/**
 * stgatilov: This GUI header is included into both in-game and main menu GUIs.
 *
 * Mission Authors: DO NOT EDIT, INCLUDE OR OVERRIDE THIS FILE IN YOUR MISSION PK4.
 */

//in principle, this can be configured from outside
#define SUBTITLES_TEXT_FORECOLOR 1,1,1,1
#define SUBTITLES_TEXT_BACKCOLOR 0,0,0,0.5
#define SUBTITLES_TEXT_BORDERCOLOR 0,0,0,1   //not sure it has any effect

//note: sizes are hardcoded for now...
#define SUBTITLES_TEXT_SCALE 0.25
#define SUBTITLES_TEXT_FONT "fonts/carleton@aspect=16:9"

//preprocessor magic for prepending window names with prefix
#define SUBTITLES_CONCAT2(a, b) a##b
#define SUBTITLES_CONCAT(a, b) SUBTITLES_CONCAT2(a, b)
#ifndef SUBTITLES_NAMEPREFIX
    #define SUBTITLES_NAMEPREFIX __MissingPrefix__
#endif

// Left & right field side margin size:
#define FIELD_MARGIN 200
// To minimize width but still accommodate 42 chars per line:
// 200 is good with 12pt (e.g., scale 0.25) font "carleton@aspect=16:9" (also scale 0.25 "stone@aspect-16:9")
// 160 is good with 12 pt font "carleton"
// Other widths tried with carleton: 170, 100, 10 [= TDM 2.11]
#define FIELD_WIDTH (640 - (2 * FIELD_MARGIN))
//#define FIELD_HALFWIDTH (FIELD_WIDTH / 2)

#define TEXT_PADDING 15
// Use 20 for uncompressed font. Details:
// #5914: engine allows overflowing textbox size by one character.
// For uncompressed 12pt carleton: maximum character width is 17 at textscale 0.25, so leave horizontal padding 20 on the right.
// For 16:9 compressed carleton: 17 x 0.75 = 12.75 --> round up to 15 padding.

#define SOUND_SOURCE_OVAL_WIDTH 30
#define SOUND_SOURCE_OVAL_HALFWIDTH ( SOUND_SOURCE_OVAL_WIDTH / 2 )
#define SOUND_SOURCE_OVAL_HEIGHT 10
#define SOUND_SOURCE_OVAL_HALFHEIGHT ( SOUND_SOURCE_OVAL_HEIGHT / 2 )
#define SOUND_SOURCE_DOT_COLOR 1,0,0,1
// Note 3:1 ratio. These are used with a .tga image of 90w x 30h actual pixels, also 3:1.

windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesHolder)
{
    rect        0,0,640,480
    visible        1
    nocursor    1

    windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesTextAndSoundHolder0)
    {
        rect        FIELD_MARGIN, 400-SOUND_SOURCE_OVAL_HALFHEIGHT, FIELD_WIDTH, 45+SOUND_SOURCE_OVAL_HALFHEIGHT
        visible    "gui::subtitle0_nonempty"

        windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesTextHolder0)
        {
            backcolor    SUBTITLES_TEXT_BACKCOLOR
            bordercolor    SUBTITLES_TEXT_BORDERCOLOR
            // visible        "gui::subtitle0_nonempty"
            rect        0, SOUND_SOURCE_OVAL_HALFHEIGHT, FIELD_WIDTH, 45

            windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesText0)
            {
                rect        0, 0, FIELD_WIDTH - TEXT_PADDING, 45
                text        "gui::subtitle0"
                font        SUBTITLES_TEXT_FONT
                textscale    SUBTITLES_TEXT_SCALE
                textAlign    1
                forecolor    SUBTITLES_TEXT_FORECOLOR
            }
        }

        windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SoundSource0)
        {
            background "guis/soundsourceoval" // .tga (could point to material shader in .mtr instead)
            rect FIELD_WIDTH/2 - SOUND_SOURCE_OVAL_HALFWIDTH, 0, SOUND_SOURCE_OVAL_WIDTH, SOUND_SOURCE_OVAL_HEIGHT
            // Center of oval is at midpoint of top field edge.
            // visible        "gui::subtitle0_nonempty"

            windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SoundSourceDot0)
            {    
                backcolor SOUND_SOURCE_DOT_COLOR
                rect SOUND_SOURCE_OVAL_HALFWIDTH - (dot0_x * SOUND_SOURCE_OVAL_HALFWIDTH) - 1, SOUND_SOURCE_OVAL_HALFHEIGHT - (dot0_y * SOUND_SOURCE_OVAL_HALFHEIGHT) - 1,3,1
                float dot0_x 0
                float dot0_y 0

                onTime 0 { // TEMPORARY, TO BE REPLACED WITH GUI GLOBAL SET BY ENGINE
                    set "dot0_x" "1.0"; // Full left
                    set "dot0_y" "0";
                }
            }
        }
    }

    windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesTextAndSoundHolder1)
    {
        rect        FIELD_MARGIN, 350-SOUND_SOURCE_OVAL_HALFHEIGHT, FIELD_WIDTH, 45+SOUND_SOURCE_OVAL_HALFHEIGHT
        visible    "gui::subtitle1_nonempty"

        windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesTextHolder1)
        {
            rect            0, SOUND_SOURCE_OVAL_HALFHEIGHT, FIELD_WIDTH, 45
            backcolor        SUBTITLES_TEXT_BACKCOLOR
            bordercolor    SUBTITLES_TEXT_BORDERCOLOR
            // visible        "gui::subtitle1_nonempty"

            windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesText1)
            {
                rect        0, 0, FIELD_WIDTH - TEXT_PADDING, 45
                text        "gui::subtitle1"
                font        SUBTITLES_TEXT_FONT
                textscale    SUBTITLES_TEXT_SCALE
                textAlign    1
                forecolor    SUBTITLES_TEXT_FORECOLOR
            }
        }

        windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SoundSource1)
        {
            background "guis/soundsourceoval" // .tga (could point to material shader in .mtr instead)
            rect FIELD_WIDTH/2 - SOUND_SOURCE_OVAL_HALFWIDTH, 0, SOUND_SOURCE_OVAL_WIDTH, SOUND_SOURCE_OVAL_HEIGHT
            // Center of oval is at midpoint of top field edge.
            // visible        "gui::subtitle1_nonempty"

            windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SoundSourceDot1)
            {    
                backcolor SOUND_SOURCE_DOT_COLOR
                rect SOUND_SOURCE_OVAL_HALFWIDTH - (dot1_x * SOUND_SOURCE_OVAL_HALFWIDTH) - 1, SOUND_SOURCE_OVAL_HALFHEIGHT - (dot1_y * SOUND_SOURCE_OVAL_HALFHEIGHT) ,3,1
                float dot1_x 0
                float dot1_y 0

                onTime 0 { // TEMPORARY, TO BE REPLACED WITH GUI GLOBAL SET BY ENGINE
                    set "dot1_x" "0";
                    set "dot1_y" "1.0"; // Straight in front of player
                }
            }
        }
    }

    windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesTextAndSoundHolder2)
    {
        rect        FIELD_MARGIN, 300-SOUND_SOURCE_OVAL_HALFHEIGHT, FIELD_WIDTH, 45+SOUND_SOURCE_OVAL_HALFHEIGHT
        visible    "gui::subtitle2_nonempty"

        windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesTextHolder2)
        {
            rect            0, SOUND_SOURCE_OVAL_HALFHEIGHT, FIELD_WIDTH, 45
            backcolor        SUBTITLES_TEXT_BACKCOLOR
            bordercolor    SUBTITLES_TEXT_BORDERCOLOR
            // visible        "gui::subtitle2_nonempty"

            windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesText2)
            {
                rect        0, 0, FIELD_WIDTH - TEXT_PADDING, 45
                text        "gui::subtitle2"
                font        SUBTITLES_TEXT_FONT
                textscale    SUBTITLES_TEXT_SCALE
                textAlign    1
                forecolor    SUBTITLES_TEXT_FORECOLOR
            }
        }

        windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SoundSource2)
        {
            background "guis/soundsourceoval" // .tga (could point to material shader in .mtr instead)
            rect FIELD_WIDTH/2 - SOUND_SOURCE_OVAL_HALFWIDTH, 0, SOUND_SOURCE_OVAL_WIDTH, SOUND_SOURCE_OVAL_HEIGHT
            // Center of oval is at midpoint of top field edge.
            // visible        "gui::subtitle2_nonempty"

            windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SoundSourceDot2)
            {    
                backcolor SOUND_SOURCE_DOT_COLOR
                //rect first parameter has -1 to compensate for dot width of 3
                rect SOUND_SOURCE_OVAL_HALFWIDTH - (dot2_x * SOUND_SOURCE_OVAL_HALFWIDTH) - 1, SOUND_SOURCE_OVAL_HALFHEIGHT - (dot2_y * SOUND_SOURCE_OVAL_HALFHEIGHT) - 1,3,1
                float dot2_x 0
                float dot2_y 0

                onTime 0 { // TEMPORARY, TO BE REPLACED WITH GUI GLOBAL SET BY ENGINE
                    set "dot2_x" "0";
                    set "dot2_y" "-1.0"; // Straight behind player
                }
            }
        }
    }
}

#undef SUBTITLES_TEXT_FORECOLOR
#undef SUBTITLES_TEXT_BACKCOLOR
#undef SUBTITLES_TEXT_BORDERCOLOR
#undef SUBTITLES_TEXT_SCALE
#undef SUBTITLES_TEXT_FONT

#undef SUBTITLES_CONCAT2
#undef SUBTITLES_CONCAT
#undef SUBTITLES_NAMEPREFIX

#undef FIELD_MARGIN
#undef FIELD_WIDTH
//#undef FIELD_HALFWIDTH

#undef TEXT_PADDING

#undef SOUND_SOURCE_OVAL_WIDTH
#undef SOUND_SOURCE_OVAL_HALFWIDTH
#undef SOUND_SOURCE_OVAL_HEIGHT
#undef SOUND_SOURCE_OVAL_HALFHEIGHT
#undef SOUND_SOURCE_DOT_COLOR

@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.

 

[stgatilov]

2 hours ago, Geep said:

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.

Oh sorry!
When I started, I tried to find the prototype, but did not find it.

Quote

 

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)

This compromise would have an advantage: the user could tell at a glance whether the clip is story (or briefing) versus a bark.

 

So you suggest to reduce the width of subtitles?
How can you even do it globally? Where would you place all the text?

Having different width depending on verbosity... that's something to think about.
I bet most people would actually care about story subtitles anyway, both players and mappers.

Maybe it would be OK to have smaller size for speech only.

[Geep]

5 minutes ago, stgatilov said:

So you suggest to reduce the width of subtitles?
How can you even do it globally? Where would you place all the text?

Having different width depending on verbosity... that's something to think about.
I bet most people would actually care about story subtitles anyway, both players and mappers.

Maybe it would be OK to have smaller size for speech only.

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)

 

 

[datiswous]

17 hours ago, Geep said:

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:

I'm not against it persé, but maybe both sides can be supported by a switch? So you set in the subs file "small-width=1" or something. This way originally created subtitles don't have to be converted, that's probably a lot of work. Also creation of the subs might be more difficult, especially if using autogeneration.

It might look better for story subs as well, because it (usually) won't cover the hud (I think), like it currently does.

14 hours ago, Geep said:

#define FIELD_MARGIN 160

Where is this specified?

Edited October 10, 2023 by datiswous

[Geep]

Quote

 

I'm not against it persé, but maybe both sides can be supported by a switch? So you set in the subs file "small-width=1" or something. This way originally created subtitles don't have to be converted, that's probably a lot of work. Also creation of the subs might be more difficult, especially if using autogeneration.

It might look better for story subs as well, because it (usually) won't cover the hud (I think), like it currently does.

 

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 

 

8 hours ago, datiswous said:

Where is this specified?

#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.