Jump to content
The Dark Mod Forums

Subtitles - Possibilities Beyond 2.11


Geep

Recommended Posts

tdm_message is shown on upper left corner, it should not overlap.
Yes, I agree that there is overlap with item pickup message, and partly with some HUD elements.

My opinion is that we should resolve this for standard GUI size, and simply ignore the problem on larger GUI size.
There is not too much space on the screen to fit everything on the maximum that GUI size allows, and I don't like the idea of making subtitles font or amount of text per message smaller.

  • Like 1
Link to comment
Share on other sites

15 minutes ago, stgatilov said:

My opinion is that we should resolve this for standard GUI size, and simply ignore the problem on larger GUI size.
There is not too much space on the screen to fit everything on the maximum that GUI size allows, and I don't like the idea of making subtitles font or amount of text per message smaller.

I'm seeking a middle ground, that would still accommodate low-vision folks. I don't think limiting the characters/line to 42 (a common limit used on streaming services like Netflix) would be a hardship, given srt capabilities. As I indicated above, with that limit and the current font size, the subtitle fields could be narrowed to 320 (i.e., half screen width). That would gracefully eliminate overlap with the corner items, except if the latter are enlarged to near-max size.

And we could put off any consideration of adjustable subtitle font sizes until 2.13+

  • Like 1
Link to comment
Share on other sites

I understand. But I'm against the current way-too-wide field length, that encourages subtitles that are either too long to read in the given time, or that have to be on-screen too long, when they should be chopped into smaller pieces.

Too much work? I bet if you analyzed your srt phrases, almost all are already under 84 characters long.


Below is a custom tdm_subtitles_common.gui that uses margins of 160 instead of 170. It's what I plan to use for The Wench testing. This should be more friendly to your existing subtitles than what came with testSubtitlesLord.

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"

//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

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

    windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesTextHolder0)
    {
        // TDM 2.11: rect 10, 400, 620, 45  // Left & right field margins of 10
        // rect        100, 400, 440, 45  // Left & right field margins of 100
        rect        160, 400, 320, 45 // Left & right field margins of 160
        backcolor    SUBTITLES_TEXT_BACKCOLOR
        bordercolor    SUBTITLES_TEXT_BORDERCOLOR
        visible        "gui::subtitle0_nonempty"

        windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesText0)
        {
            // #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
            // TDM 2.11: rect 0, 0, 600, 45
            // rect        0, 0, 420, 45
            rect        0, 0, 300, 45
            text        "gui::subtitle0"
            font        SUBTITLES_TEXT_FONT
            textscale    SUBTITLES_TEXT_SCALE
            textAlign    1
            forecolor    SUBTITLES_TEXT_FORECOLOR
        }
    }

    windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesTextHolder1)
    {
        // TDM 2.11: rect 10, 350, 620, 45  // Left & right field margins of 10
        // rect        100, 350, 440, 45  // Left & right field margins of 100
        rect        160, 350, 320, 45 // Left & right field margins of 160
        backcolor    SUBTITLES_TEXT_BACKCOLOR
        bordercolor    SUBTITLES_TEXT_BORDERCOLOR
        visible        "gui::subtitle1_nonempty"

        windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesText1)
        {
            // TDM 2.11: rect 0, 0, 600, 45
            // rect        0, 0, 420, 45
            rect        0, 0, 300, 45
            text        "gui::subtitle1"
            font        SUBTITLES_TEXT_FONT
            textscale    SUBTITLES_TEXT_SCALE
            textAlign    1
            forecolor    SUBTITLES_TEXT_FORECOLOR
        }
    }

    windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesTextHolder2)
    {
        // TDM 2.11: rect 10, 300, 620, 45  // Left & right field margins of 10
        // rect        100, 300, 440, 45  // Left & right field margins of 100
        rect        160, 300, 320, 45 // Left & right field margins of 160
        backcolor    SUBTITLES_TEXT_BACKCOLOR
        bordercolor    SUBTITLES_TEXT_BORDERCOLOR
        visible        "gui::subtitle2_nonempty"

        windowDef SUBTITLES_CONCAT(SUBTITLES_NAMEPREFIX, SubtitlesText2)
        {
            // TDM 2.11: rect 0, 0, 600, 45
            // rect        0, 0, 420, 45
            rect        0, 0, 300, 45
            text        "gui::subtitle2"
            font        SUBTITLES_TEXT_FONT
            textscale    SUBTITLES_TEXT_SCALE
            textAlign    1
            forecolor    SUBTITLES_TEXT_FORECOLOR
        }
    }
}

#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

 

  • Like 1
Link to comment
Share on other sites

The problem with tweaking size and font is that any such change breaks existing subtitles.
If you do that, you have to review all released subtitles. Maybe now it is only New Job and Saint Lucia, but as time goes, it would become virtually impossible.
Just remember what happened recently after a small overflow fix in readables.

So the issue of overlaps with item pickup message and HUD should be resolved quickly, and after that fixed forever.
Reducing width and font size is perhaps the easiest approach now.

  • Like 2
Link to comment
Share on other sites

I wasn't proposing ever changing the font itself from Carleton, which I agree would be problematic.

With respect to scaling the fontsize, if the adjustment process also carefully scales the field dimensions to match, it should not affect (or at least affect little) where auto-wraps occur. And this would further help with low-vision, which seems to me the whole point of the similar size adjustments in the HUD. So "fixed forever"... nah. But "fixed for the next bunch of official releases"... sure.

For now, what I very much want is a policy on the maximum number of characters on a subtitle line. Then, a fontsize and fieldwidth can be determined that support that nicely, while minimizing corner overlap.

As a first draft, I proposed:

  • 42 characters max
  • current fontsize: SUBTITLES_TEXT_SCALE 0.25
  • fieldwidth of 320

This would need more fulsome testing. It may be a slightly smaller fontsize or slightly larger fieldwidth is needed. As to the maximum character limit, if you google "subtitle character limit", you'll see that "about 42" seems most popular, with a range from 37 to 47.

It would not be hard to write a program that, for a given FM, looked at all the subtitle lines in the .sub and .srt files and reported any that exceed any maximum number of characters. The FM author could then adjust those strings accordingly. Sure, it's more work, but kinda trivial in the big scheme of getting an FM out. And it is a one-time fix.

I'm willing to write such a program, if I knew it would be used. (My Excel template provides the similar functionality that I use at the moment.)

  • Like 1
Link to comment
Share on other sites

There is no such thing as "number of characters that fit", since font is not monospace.
The number of characters per line depends on the particular characters.

So no, you cannot resize subtitle message while saving exactly the break locations.
Except maybe for exactly proportional scaling of both message elements and fonts.
I hope that is possible, but not sure.

  • Like 1
Link to comment
Share on other sites

That's true, but given a corpus of representative text (which we have with the subtitles done so far), we can estimate length distributions, and cover 99.9% of representative real sentences. Takes some analysis, but do-able.

  • Like 1
Link to comment
Share on other sites

That's true. But most TDM fonts have slow readability, which is definitely not what you want in a subtitle. "Stone Print" would be a good substitute for Carleton.

I'm not sure we never need a subtitle background. But it could be made a user choice, with a CVar toggle on/off.

Regarding moving subs up, this is another compromise. Given that there are up to 3 stacked 2-line subtitles possible, and existing FMs that show messages centered on screen.

  • Like 1
Link to comment
Share on other sites

56 minutes ago, stgatilov said:

With a different font, we will probably get narrower messages automatically.

Yes. And since we don't read words but "kind of guess them", the cleaner the typeface and the better the format the faster we go through sentences, meaning less screen time required.

12 minutes ago, Geep said:

I'm not sure we never need a subtitle background. But it could be made a user choice, with a CVar toggle on/off.

I would just disable the background for the rest of your exercise. See if you detect something or miss anything.

In-game, players will organically move the mouse to darker areas if the text (or part of) gets obscured by a white texture. The background could perhaps stay for intros and cut-scenes. Or, you can try employing the "double print" technique.

I know all this is easier said than done, but thanks for listening.

  • Like 1

TDM Modpack 4.0

Link to comment
Share on other sites

10 minutes ago, snatcher said:

I would just disable the background for the rest of your exercise. See if you detect something or miss anything.

In-game, players will organically move the mouse to darker areas if the text (or part of) gets obscured by a white texture. The background could perhaps stay for intros and cut-scenes. Or, you can try employing the "double print" technique.

Definitely won't do it.

The first implementation did not have background, and it was hard to read subtitles on top of some bright parts in briefings. Background is here to ensure that text font is in contract with whatever the game displays below.

  • Like 1
Link to comment
Share on other sites

I'm proposing the width be reduced to half-screen; that's relatively easy. I'm not opposed to smarter and more tight-fitting background management, while recognizing that's technically more challenging.

  • Like 2
Link to comment
Share on other sites

I'd like to follow up on an earlier post, that keeps with the simple approach of retaining a fixed subtitle fieldwidth.

Regarding about how one might test that a subtitle fieldwidth is "just right" for a given subtitle-line character limit (e.g., 42/line), font, and font scale, here's what I would suggest.

Using dummy sound files, create a set of about 100 "worst likely case" subtitles that are exactly the length of the character limit. These are directly derived from the corpus of existing "story" and "speech" subtitles. Turn this set into 100 sound shaders for another version of my testSubtitles... program (with the desired fieldwidth, font, and font scale under test), and step through them. What you are looking to achieve is NO auto-wrap from the first to second line. If you get auto-wrap, then adjust the font scale and/or fieldwidth and iterate until good.

This gives assurance about "worst likely cases", not "worst possible case", e.g, 42 W's in a row.

Details:

Suppose you have a function that takes a subtitle string and a font, and returns the "draw length" of that string in internal scale-independent font units, that is, pre-scaling/rendering. It's just a summation of lookups into the appropriate static character-width table (assuming kerning is not an issue). Because we will be using the calculated value just to rank the strings for "worse-ness", the "font unit" is arbitrary. [ @stgatilov, maybe you could provide me with such a function in C++? Then I could do what follows. ]

OK, so that is embedded into a program that is turned loose on the existing subtitles, to:

  • look for 2-line subtitles (in inline or srt form) where the lines together exceed the character limit
  • convert those to a single string by replacing the linebreak with a space
  • truncate them to the character limit
  • calculate the "draw length" of each
  • export the strings and their draw lengths into a csv (along with a field indicating the source)

Do that for each available subtitle source (FM or stock barks), and import all the .csv files as sets of rows in a spreadsheet. Then sort the rows by draw length and deduplicate (ignoring source). Take the 100 "worst likely case" rows, export them, and turn them (using techniques already developed) into sound shaders for the testSubtitles... program.

So, a bit of work, but you get assurance that you've optimized things to minimize future problems.

  • Like 1
Link to comment
Share on other sites

I've built another console utility program, "findTooLongSubtitles". This can be pointed at any directory with .subs or .srt files, and will find all lines within, that are longer than what you specify (default is 42 characters/line).
I'll be using it for barks, but it relates to what we are discussing here more broadly. I pointed it at 2.11's newjob FM, and generated this results:
 

Spoiler


Subtitles with One or Both Lines Longer than 42 Characters in Folder
<my private dev machine path>/[2.11]/newjob/subtitles/

Subtitles in briefing.srt, by srt phrase number:
6)      My job is to acquire valuable items for the rich [48]
8)      but these items are usually owned by someone already [52]
11)     Tonight I'm meeting someone who wants to hire me for a job [58]
12)     I don't know the details yet but an associate of mine has vouched for him [73]
13)     and the message managed to pique my interest [44]
14)     I'm supposed to meet my contact in a courtyard south of Canonbury Tavern [72]
15)     Canonbury is popular with wealthy travellers [44]
16)     and it just so happens that a Lord Rothwick is staying there tonight [68]
17)     I'm told that he has a purse full of very expensive rubies with him [67]
18)     I've decided to arrive in the area a little early and engage in a bit of burglary [81]
19)     A tavern won't have the same level of security as a private estate [66]
20)     and it shouldn't be too difficult to find what room Lord Rothwick is in [71]
22)     I can help myself to that purse and still meet my contact in the courtyard on time [82]

Inline subtitles in fm_root.subs, by line number:
7)      The back alleys of Bridgeport. You can get almost anywhere unseen, if you know your way through the maze. [105]
8)      I can probably get up on that pipe if I can find something to stack. [68]
9)      The City Watch makes the main streets a lot riskier. Even regular citizens might raise a hue and cry if they see someone dressed like me. [137]
11)     There's the tavern. That guard in front is the problem. I'll need to distract him or find another way in. [105]
12)     A one-eyed guard. This must be my lucky day. [44]
13)     That's where I'm supposed to meet my contact. Looks like he's not here yet. [75]
15)     My work here is done. Time to meet my contact. [46]
17)     The old man says the Builders are harrassing the girls behind the Inn. Says it's bad for business [97]
18)     What does he want us to do about it? Builders don't carry those hammers for decoration you know. They'll bash your skull in right quick and who's going to stop them? [165]
19)     You think a Church court'll hang one of their own? A wink and a rap on the knuckles, that's what they'll get, and they'll be back on the street by breakfast. [157]
20)     The City needs to put a stop to it! You let a dog roam free in the kitchen long enough and soon he thinks he owns all the food. [127]
22)     Hey did you see the Moorish guards they have protecting the vizier? [67]
23)     I wonder what those curved swords would be like in a fight? [59]
25)     They say the Moors can use magic to summon genies and wind and stuff. [69]
26)     They fight by summoning genies. What do they do huh? Rub a lamp? [64]
27)     And winds. They can summon really really strong winds. [54]
28)     Oh sure. Better make sure the washer wench doesn't pick a fight with one on laundry day then. [93]
31)     You read in the papers about that statue weeping blood? [55]
32)     Yeah. My uncle went and saw it. Said it cured his gout. [55]
33)     Hmm. I wonder if it will put that hospital out of business. [59]
35)     It'd be out of business already if Lord Belhaven wasn't paying for the whole thing himself. [91]
38)     If you'll follow me we can talk about the details [49]

The first thing to notice is that there are two files, dealing with "story" captions. The first covers the audio briefing, as a long series of phrases in a .srt file. The second has the inline subtitles. Neither of these explicitly have linebreaks set, so both rely on word-wrap to make use of the second line. This is not ideal.

Even so, many, but not all, would still fit as-is into a half-screen-wide subtitle field; namely, those that are roughly under 84 characters (2 x 42). In the briefing, all would likely fit, except two (#18 & 22) would be marginal. For the inline, 13 would seem to fit, but 9 need to be converted from inline to srt.

All subtitles would benefit (not just the ones in this printout) from explicit line breaks that would make intelligent use of sentence structure.

BTW, this utility program will be released in a day or so.

  • Like 1
Link to comment
Share on other sites

10 hours ago, stgatilov said:

Definitely won't do it.

The first implementation did not have background, and it was hard to read subtitles on top of some bright parts in briefings. Background is here to ensure that text font is in contract with whatever the game displays below.

Would be to hard to do drop shadow for the text? Afaik that (and or using other color than white text like you see in thief 3) is how almost everyone solves that bright text over bright backgrounds.

 

subexample.gif

P.S Unfortunately the example image I attached, looks worse than I thought, but in the real thing the text with drop shadow is very visible. And the drop shadow can be made stronger than that.

Edited by HMart
  • Like 2
Link to comment
Share on other sites

What function are you using to render the subtitle text? Is it idRenderSystemLocal::DrawSmallStringExt() ? The comment above it says it does drop shadow but I didn't analyzed the code at all to know if true.

That 480p virtual background rendering, does sounds like a problem, too text at lest, specially when you guys are still using the text textures at max 48 size, like Doom 3. The engine is essentially using the same "basic" text system from quake 2 or even quake, texture atlas, and it makes for blurry text when scaled, specially from 480p.

Btw no pressure here just a suggestion, if you haven't looked at the OverDose source code imo you should, they claim is a very advanced quake 2 engine but internally, looking at it, is almost identical to idTech 4 but with a more advanced modern GL render just like TDM engine :) .

I'm talking about that engine, particularly because they upped the text atlas scale to max 96 and you could look how they did it, that should help a little with the blurry text. And IMO, not affect performance that much, specially today when thanks to your fantastic job TDM engine is so fast.  Also they even have a nice tool to create fonts for their engine (and other tools and documentation, some of it imo still relevant for Doom 3 editing and perhaps even TDM).

And lastly I know is probably not possible and would be a bunch of work for you and I bet you are already busy with other more pressing things but some day, something similar to this would be awesome, if a open source equivalent exists...

  • Thanks 1
Link to comment
Share on other sites

16 hours ago, datiswous said:

How do you set line breaks in srt files?

The srt "spec" say to do it this way (shown in phrase 2):
 

1
00:00:00,180 --> 00:00:03,300
It's far too late now.

2
00:00:03,710 --> 00:00:07,470
I'm going to have to go
to the market tomorrow.

I've been assuming TDM's parsing implements this, but haven't yet been in a position to test that. You? If it doesn't, time for a bug report. (If you do test this, please let me know what you find. Also, if it doesn't work, you could try embedding a "\n" as a temporary workaround. That may or may not work. If it does, I'll need to alter my findTooLongSubtitles tool to support "\n" in srt, not just inline.)

  • Like 1
Link to comment
Share on other sites

3 hours ago, stgatilov said:

I think part of the problem is that fonts are rendered into virtual 640:480 resolution, which is later resized to 16:9 or whatever aspect ratio you have.

Yeah, it's both bad and good. The bad is that the letter glyphs were designed for a 4:3 world, and are widened with 16:9; so they are not as narrow as you might like for captions. The good is that the background fieldwidths are identically scaled, so compatible with limits like "characters/line", that should work independent of display aspect ratio.

  • Like 1
Link to comment
Share on other sites

13 hours ago, HMart said:

Would be to hard to do drop shadow for the text? Afaik that (and or using other color than white text like you see in thief 3) is how almost everyone solves that bright text over bright backgrounds.

Those are 2 ways to solve it, in addition to current TDM method (fixed-width translucent field spanning 2 lines).

Others are -

  • Have an outline font, that is, white with black background borders. Done right, this can be more reliably readable than drop shadows. Some foreign films use this. Probably a heavy lift for TDM.
  • Have a dynamically-sized background rectangle (either black or dark translucent) that is a slightly-enlarged bounding box around each line separately.

That last one is would probably also be more readable than drop shadows. All of these alternatives would mean less obscuring of the player's world view by translucent panels. That said, TDM isn't the only one using that panel style for captioning.

 

 

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Ansome

      Turns out my 15th anniversary mission idea has already been done once or twice before! I've been beaten to the punch once again, but I suppose that's to be expected when there's over 170 FMs out there, eh? I'm not complaining though, I love learning new tricks and taking inspiration from past FMs. Best of luck on your own fan missions!
      · 4 replies
    • The Black Arrow

      I wanna play Doom 3, but fhDoom has much better features than dhewm3, yet fhDoom is old, outdated and probably not supported. Damn!
      Makes me think that TDM engine for Doom 3 itself would actually be perfect.
      · 6 replies
    • Petike the Taffer

      Maybe a bit of advice ? In the FM series I'm preparing, the two main characters have the given names Toby and Agnes (it's the protagonist and deuteragonist, respectively), I've been toying with the idea of giving them family names as well, since many of the FM series have named protagonists who have surnames. Toby's from a family who were usually farriers, though he eventually wound up working as a cobbler (this serves as a daylight "front" for his night time thieving). Would it make sense if the man's popularly accepted family name was Farrier ? It's an existing, though less common English surname, and it directly refers to the profession practiced by his relatives. Your suggestions ?
      · 9 replies
    • nbohr1more

      Looks like the "Reverse April Fools" releases were too well hidden. Darkfate still hasn't acknowledge all the new releases. Did you play any of the new April Fools missions?
      · 5 replies
    • The Black Arrow

      Hope everyone has the blessing of undying motivation for "The Dark Mod 15th Anniversary Contest". Can't wait to see the many magnificent missions you all may have planned. Good luck, with an Ace!
      · 0 replies
×
×
  • Create New...