Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Geep

  1. Now that I think about it, "duration" needs to be expressed in terms of each srt phrase. So the equation you gave is good for a single-phrase srt that starts at time 0. More generally: start = phrase start time (within clip) stop = phrase stop time diff = stop - start In most cases: d = diff For the final phrase, there is this constraint: stop = min(LastMessageEndTime, SoundDuration + tdm_subtitles_durationExtensionLimit) But are these globals also applicable to SRT? the 1.0 second lower bound (I was calling L) the 0.2 extension (I was calling X) BTW, how are overlapping time ranges within an SRT handled?
  2. Good to know! Since SRT now has it's own way of extending (using end time of last phrase), there is probably not a need for -dx with srt. Hmm, I wonder what the calculation of d is for SRT. Probably could use this variable: e = end time of last phrase within srt Then maybe redefine variable x as: x = e - c In this case, x could be negative or positive. Then tie it in to the 3 internal globals. Maybe differs from inline.
  3. OK, I would express this as: d = min(max(c + X, L), c + U) if x not defined d = min(max(c + x, L), c + U) if x defined (where x > 0) In this formulation, if the user chooses to set the maximum extension U to zero, then the values of x, X (default 0.2), and L (default 1.0) have no effect. Soon I hope. I can't finalize any more vocal sets barks until then. I'm not clear how parsing is dependent on line breaks here. I mean, this would be OK: inline "say1.ogg" "Hello, world" -x 0.3 inline "say2.ogg" "Goodbye" That said, I'm not wedded to "-x", but I would very much like to have the extension value either part or adjacent to the inline statement it modifies. Ideas: inline "say1.ogg" "Hello, world" "" // last parameter is no longer optional, but if "", then treated as if not given or inline "say1.ogg" "Hello, world" inline-extend 0.3 // or maybe inline-extend "say1.ogg" 0.3
  4. Actually, there are additional possibilities where X and x are not additive, but alternatives: a.4) d = max(c,L) + min(X,x,U) a.5) d = max(c,L) + min(max(X,x),U) a.6) d = max(c,L) + min(x,U) // iff x > 0. In that case, x overrides X b.4) d = max(c + min(X,x,U), L) b.5) d = max(c + min(max(X,x),U), L) b.6) d = max(c + min(x,U), L) // iff x > 0. In that case, x overrides X
  5. @stgatilov, I started to apply the inline "-x" option for extra time to a vocal set, but then realized that I needed to know better how it worked, in order to choose appropriate values. So some questions: 1) Does the inline -x work... a) the same for "story" and "speech" verbosities b) differently If (b), the next questions will need to be answered twice. I'm going to state these in mathematical terms, summarizing the behavior of the algorithm and reflecting the order in which values are combined. All variables are in seconds. c = length of a given sound clip x = inline -x value for extra time. Should be positive. Zero if not given. d = calculated length of subtitle duration L = global giving a lower bound on subtitle duration. Default is 1.0 X = global giving an extension to subtitle duration. Default is 0.2 U = global giving an upper bound on X. Default is 5.0 2) When there is no value of x, which equation describes the algorithm's behavior? a) d = max(c,L) + min(X,U) b) d = max(c+min(X,U),L) 3) When there is a valid value of x, the equation becomes... a.1) d = max(c,L) + min(X,U) + x a.2) d = max(c+x,L) + min(X,U) a.3) d = max(c,L) + min(X+x,U) b.1) d = max(c+min(X,U),L) + x b.2) d = max(c+x+min(X,U),L) b.3) d = max(c+min(X+x,U),L) Thanks for help with this.
  6. Books are out of scope for this thread, which is just concerned with subtitles. As an aside, because of the way book text is laid out (separate independent overlays for "title" and "body" text), changing the font from what the FM author provided would tend to make a mess.
  7. @datiswous, I'll try to incorporate Skip Forward/Backward buttons (or whatever I end up calling them) into the upcoming testSubtitlesWench release. Likely sometime next week.
  8. An update of command-line tool "buildSubtitleShaders" is now available: Win executable C++ source code file With this Feb. 10 version, if you ask for help (buildSubtitleShaders -h or ?), there's an additional option shown: -c counter start value (default: 1). Eases merging results from different sound file folders. As before, comments in the source code file provide full documentation.
  9. Yeah, that is a pain in the butt. The main problem with multiple input folders is that you really want to be able to specify relative paths on the command line (i.e., not just absolute), but then reformulate the paths into the form that TDM wants in the sound shader. I tried to code that earlier, and ended up with a real mess. One of those situations where the more you try to fix, the worse it gets. So I abandoned that attempt. What I could do instead, fairly easily, is to provide another command line option that would let you specify a starting number greater than 1, so you wouldn't have to separately renumber. EDIT: See next item.
  10. ??? If you don't specify the output file, then it writes to stdout. The expected behavior would be you would see the output on the terminal screen, unless you did something like "> my_new_results.sndshd". Are you not seeing that with wine? No, you currently would have to run the program separately for each folder and cut/paste to merge the outputs by hand. Since that's kinda trivial, and programming for multiple input folders less so, probably won't be happening. I'm thinking here you're talking about a "testSubtitle..." FM. So in addition to jumping to a particular soundfile by changing the cursub value in the console, you'd maybe like 2 more in-game buttons, to skip forward and skip backwards?
  11. You might want to manipulate inventory items & count, & available weapons, too. Some scripting support, but varies.
  12. The Wench bark subtitles are essentially done, but there are some issues with a handful of .ogg files (see new bug tracker report #6284). So I'm holding up release pending resolution. I'm going to briefly revisit the subtitles for the first 2 AI characters, to make better use of SRT and of the new duration-extensions capabilities in 2.12dev.
  13. I agree that listdefs as they are now are not useful to FM authors, because alteration of the C++ source code is needed. If there was some data array that was useful across FMs, then it might justify a collaboration to have C++ support it. For instance, I could imagine a generic fm_data_string_array, with read/write access, that you could associated with any FM-specific listdef. Don't have a clear idea here.
  14. Also, I was interested in getting metadata about the TDM fonts. Some forum posts suggested you just rename a font's .dat file to .ttf, and then font tools (like those provided by FreeType) could read it. But all I'm seeing is an unrecognized file format when a read is attempted. ???
  15. @stgatilov, this is precisely where our views diverge. We're both interested in a narrower, aspect-corrected font, but for different reasons: You're looking to increase the amount of text than can be held... I'm looking to make the backing fieldwidth less wide, and think there's already too much text per subtitle. A possible compromise would be to make the fieldwidth 2/3rds of the screen. This would maintain the current amount of text, given the current font but now aspect-corrected. Probably more text (ugh) with the Stone font, aspect-corrected.
  16. I have argued that the 2.10/2.11 implementations have field widths that are way too wide, unpopular with most subtitling orgs, and conflicting with TDM's corner inventory and weapon icons. So breaking backward compatibility now would be a good thing, before it's too late and too many FMs are subtitled targeting wide fields. But I can only suggest, and continue to make my bark subtitles fit in a less-wide field, taking into account sentence and phrasing breaks. Future automated text conversion update tools could be helpful.
  17. No consensus has been reached on changes. Certainly I have a subtitle style I prefer, and applying that style to briefings and other story subtitles would no doubt mean changes for some existing subtitles. This would not be much work for inline subtitles. Breaking up over-long srt phrases would take more work. You could pause or slow-walk subtitling if you think warranted.
  18. True. Or shorten it to -x 0.123, where -x stands for Xtra time. I guess you mean that some scale factors cause poor font rasterization. Let's start there.
  19. Rather than bundled subtitling themes, I'd like to see more flexible offerings, namely two new Settings for Subtitle Font Size Subtitle Font In the .gui, Subtitle Font size would directly tell the .gui how to scale the font. Together, the two settings could allow the .gui to intelligently adjust the backing fields; some .gui code experimentation would be needed. How about this? This optional parameter, in units of seconds, should be the last one in a line, preceded by a space. Probably doesn't need enclosure in double quotes, but that would be OK if you find it makes parsing easier. Specifying an amount of extra time, rather than the amount of total time, seems safer to me. An ideal format would be 1 digit before the decimal point, up to 3 after it. So typical: 0.1, 0.25, 0.125
  20. Which leads me to wonder again why DR doesn't offer quick & easy smooth cylinder creation.
  21. Currently the fieldwidths are a fixed proportion of the screen width (e.g., 90%). In the example images, there is the suggestion that the fieldwidth would be adjusted for aspect ratio instead. So a fieldwidth of 90% for a 4:3 screen becomes, for a 16:9 screen (with a 0.75 reduction) a fieldwidth of 67.5%. That is, about 2/3rds of the screen.
  22. For the record, there is much about these examples I dislike: The subtitles here are way too lengthy and should be broken up into individual sentences. Subtitle sentences should be always terminated, e.g., with periods. No terminator means the sentence continues in the next subtitle. And I continue to make the case that these default panel fieldwidths are too large. As you know, I'd like half-screen, but could I suppose, live with up to 2/3rds. Having a less-wide default means that the player could then make it wider with a new future Setting that scales up (or down) fontsize too. So if enlarged, better support for low-vision users, and if shrunken, less obstrusive for eagle-eye'd English-as-second-language users.
  23. The bottom example would be preferable to me, provided the default fontsize overall (not just the width) was enlarged by around 15%, to make lower case read faster. This would make the string about the same width as the top example.
  24. Yes, probably using @datiswous's latest test map. And maybe more clues will appear: @nbohr1more just asked datiswous whether it is possible to narrow down which dev version broke things.
  25. Good hunting, to get it down to a 2.09 vs 2.10 change. A bug report and stgatilov from here.
  • Create New...