Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Geep

  1. OK, I understand. I will revert the spacing changes. But I'm looking at some other issues in that DAT file, so won't happen until around next week.
  2. If I open and dock a 2D window and then change it from X-Y to, say, Y-Z, it doesn't seem to remember that latter change across DR sessions. A small pain.
  3. Is this really a problem? Maybe we can figure that out before reverting the "J", which previously was so badly spaced it looked like it had a space character after it. It would be helpful to identify which missions have such pseudographics. I suspect it's a small number. And those using Stone font smaller still. In that regard, I did some preliminary experiments, limited to a cohort of 46 FMs on my machine with expanded FM .pk4s, that I can do full-text searches across files on, with TextPad. (@stgatilov, I imagine you are in a position to similarly and more conclusively search the entire english FM collection.) I searched with characters (or short strings) that would be likely to be found in pseudographics. For untranslated FMs, I searched in filenames of form *.xd . For translated FMs (those that had string "#str_" in their *.xd; there were 8 such FMs in my cohort) I searched in file english.lang Results Many search strings were useless due to too many false hits: "_" Widely used as part of internal xd name. Used on separate line as heading underscore. "/" Widely used as part of internal xd name. "\" (except "\\") Widely used \n or \" escape character "--" (assuming single dash is everywhere) Several in a row to bracket a heading, or as part of a letter's signature. Used on separate line, as heading underscore or as border between paragraphs These search strings were moderately useful, showing up in just a few FMs (tho none were pseudographics on examination): "=" Used on separate line as heading underscore (in penny3's erasing.xd) "+" Used as bullet points, or (several in a row) to bracket a heading (in penny3's erasing.xd; in bcd's english.lang) These search strings were most promising: "|" Only 1 hit, but it's a table-form pseudographic! (northdale1's snowedinn.xd) "\\" (i.e., escaped \) No hits found in my cohort Inspection of snowedinn.xd showed this: Note that it uses book_calig_mac_humaine.gui; so this pseudographic was not in Stone font
  4. Hmmm, interesting. But Stone is not a monospaced font, so trying to do pseudo-graphics using Stone (if that was indeed what was used) would already be pretty difficult.
  5. I haven't used DR in a while, and saw that my old layout was gone. Trying to muck about and re-establish some half-assed approximation of that took a while. Problems I had: "View -> New XY View" . OK, I need an YZ view, does that cover it? Took a while to determine, yes it does, you have to use Ctl-Tab to get to alternatives. (Never used that much in the past, once I had my 3 orthogonal views). HOWEVER, with this new system, sometimes I would create the 2D view, but couldn't then direct Ctl-Tab to it. Bug? It became clear after a while that there were some places you could dock, and some not, and that the blue haze would indicate that. And that those locations might change depending on what you did before. One problem for me was I had a 2D view that I wanted to dock in the right lower corner, but it would only do a full-height docking. And after a full-height dock, there was no way to grab a corner handle to make it less than full height. I'm not asking for that feature... I just wish I had a reasonable understanding of the best way to sequence and manage the horizontal and vertical splits. So: Do update the now-obsolete section of the user manual, and ideally provide a thorough video to illustrate the new system. (Sorry, datiswous, your vid above is not it.) Hint: That unrushed video, with audio, should demonstrate how to approximate each of the old layout styles.
  6. I've just been reading through some old forum posts about correcting fonts. One of the points Tels makes is that, if correcting a font used in readables, you need to avoiding changing any character's spacing (I read this as xSkip value), to prevent changes in existing FM readables with that font. I suspect this advice is too conservative. You want to avoid enlarging an xSkip, because the resulting changes to wordwraps could potentially lead to line or paragraph truncation. Making an xSkip smaller could lead to wordwrap changes, but these IMHO would be unlikely to be harmful. In that regard, here's the situation with my changes to english Stone fontimage_24.dat (see a few posts previous as File Update for Improved Subtitle Font). Only a few characters got altered xSkips. Of those, the angle brackets were unlikely to be used in an existing readable, because they showed garbage glyphs. The "|" was xSkip-shortened, but also unlikely in readables. Only the badly centered and so xSkip-shortened "J" is thought to have potential to affect existing wordwraps. I have argued here that xSkip shortening is OK. However, I'm willing to revert spacing changes for "|" and "J" if people feel strongly otherwise.
  7. Anyone have a working link (or can create a link) to the modified version of ExportFontToDoom3 executable? This 2009 version was created by Crispy, to handle 256 chars instead of just 128. It was released in this forum post: the dark mode readables ttf fonts The following links to it are now dead: - crispy's original release: http://www.inventivedingo.com/stuff/exportfonttodoom3_modified.zip This is what's listed at the bottom of Font Conversion & Repair as as "Fixed version of ExportFontToDoom". - Hyeron's 2009 upload: http://www.4shared.com/file/151870191/d47d0e16/exportfonttodoom3_modified.html - tels 2011 mirror: http://bloodgate.com/mirrors/tdm/pub/exportfonttodoom3_modified.zip. No luck with wayback machine, github, sourceforge, either .exe or source. (Source & exe for unmodified version from Grant Davies is in hand.)
  8. File Update for Improved Subtitle Font As requested a while ago, to address the stray marks and other problems seen with current subtitle font, Stone, I am providing a short-term fix for characters in the printable ASCII range 32-126, using corrected metadata: fontimage_24.dat This is intended to replace tdm_fonts01.pk4\fonts\english\stone\fontimage_24.dat No change is needed in the related .dds files for this. Briefly, problems with stray marks found to the left of a character were due to picking up pixels from an adjoining character in the glyph bitmap dds files. Adjusting the location of the source box and related metrics fixed these. Affected were: % C E T W Y | The | character also got improved spacing, as did J Finally, the entirely screwed data for the angle brackets was corrected. This coming month I hope to work up a wiki page with diagrams to better explain what I learned about the mysteries of the idTech4 font .dat and .dds files. To see what the results look like with corrected fontimage_24.dat in place (as an override), here is my testing FM: testSubtitlesASCII.pk4 A longer-term fix (beyond 2.12 release) would also address ANSI and TDM-specific-mapped charaters in the range 128-255. To look at that, I have a similar experimental tester for ANSI (unripe to release). It shows substantial issues in that range. And then there's also consideration of fontimage_12.dat and fontimage_48.dat. And the russian-character variant.
  9. Yeah, I had the benefit of a vocal script for most utterances, to decipher what they were saying. In a few cases, I had to listen over and over, and then make a best guess. Their chatter usually makes sense, but not 100.000%
  10. Maybe it would be possible for the user to just bind a hotkey to toggle subtitles on/off?
  11. Related to looking into the stray marks associated with Stone font characters... I've noticed that the nominal 12 pt DDS (which as discussed above only kicks in under 8 pt) has only ASCII glyphs... nothing with code points above 127. Maybe that's why the corresponding 12 pt DAT file was not distributed, as a workaround to force the engine to use 24pt instead, because tels never got around to finishing the low-priority aspects of the project. The 24 pt DDS does have the ANSI glyphs. At a glance, most are fine; a few are a bit ragged. I didn't check compliance and completeness with TDM's character map as given on the wiki. I don't feel ANSI improvement is a 2.12 item. I've got a test FM to show all the characters. At some point, after refinement, I'll post a link.
  12. It's another aspect of, over time, tailoring the degree of subtitles shown to reflect the needs and preferences of the individual player. I think some low-hearing/audio-off players might appreciate brief soundscape descriptions, including weapon sounds; others would find it clutter. I understand that distinction is not personally of interest to you. For now, a fourth category is just theoretical, not a 2.12 item. I'm just asking for a different description of the existing category, other than "effects", that we can both live with. Something that sounds more human. How about "expressions"? If we can agree on a term, then I will revise the appropriate barks to use it.
  13. I like the widget, but I'd love it to be an optional thing, toggled on/off by setting and/or CVar.
  14. Sure, and a similar mechanism, not yet existing, could load translated subtitles, for Polish, Czech, etc. Sounds like 2.13+ to me. That is the main use case at this time. My own desire is not to limit it to that.
  15. Hmm, interesting. The _12 version appears to be picked up at textscale of 0.15 or lower. So you'd have to get down to appx 7 pt type to start using the _12 as source, given my understanding that textscale 1.0 = 48 pts. Kinda baffling.
  16. Yeah, I tried to do that sparingly. It's that low-hearing/audio-off vs normal-hearing/audio-on tradeoff again. Mostly did it when the text itself could be interpreted differently depending on tone. Like sarcasm. Current mechanism would make that hard to add as an option.
  17. I know we disagree on what an "effect" is. To me, it's a non-human sound. So an arrow hit, or a raven call. Primarily to benefit low-hearing players. I would be fine with having a fourth category, between speech and effect. Let's call it maybe "vocal sounds". Here would go the barks that contain zero words. So, snores, cries of pain, some mutters; barks currently translated as just "(sigh)" or "AAiiee" In the short term, if you just fully implement 3 categories, but rename the 3rd category as "vocal_sounds" (or "vocalizations" or whatever), so there would be a "verbosity vocal_sounds" in .subs, then I'd be willing to redo the barks subtitles to use that.
  18. At least for bark subtitles, fast readability is important, because they shouldn't be on the screen much beyond the vocalization time, and for fast talkers, that's not real long. Of the existing fonts available, Carleton and Stone are the easiest to read quickly at a glance. If you were going to allow a different font for story subs, assuming they are generally articulated at a more leisurely pace, then you could consider a more "themed" font. Still, a lot of TDM fonts are pretty slow to scan/parse.
  19. I think this is probably "it depends". If a single AI is giving a story monologue, it may be implemented as a single .ogg file, just broken up into subtitles. So this would all be in the same slot. (Likewise, there are some long barks in a single .ogg file too). But the story could be in multiple .ogg files, delivered by one or several AI. Then, the slot could vary, if there also barks happening that scrambled things up. I could be wrong about this. I recall there was some chatter a long while ago about making what slot an particular AI uses somewhat sticky. That's interesting, about volume (or distance) threshold triggering of subtitle display. I'm guessing no threshold test is applied for story subs.
  20. @stgatilov, I've been looking into the stray marks associated with Stone 12 pt. Not much progress, because there's something strange going on. Any change I make to the metadata in fonts/english/stone/fontimage_12.dat (whether in the core or as an FM "/fonts/" override) is ignored. Whereas changes to the corresponding 24 pt .dat (whether in core or override) do show up in the nominally 12 pt subtitles (with either gui textscale of 0.24 or 0.25). Is there something in the engine code that is keeping this 12 pt .dat from being used? There are no warning about such at startup. Perhaps some engine hack left over from when there was a missing file?
  21. I think moving them to the FM-specific folder would be the right thing to do.
  22. Be interesting to know if reloadDecls works on an edited core .subs but not on an edited FM-specific .subs
  23. There's nothing about .subs or .srt files that says to me: these are decl files. So reloadDecls and reloadXData are equally arbitrary. On the other hand, "reloadSubtitles", yeah, that I would understand.
  24. There's good news and bad news. The good news is that this zip file does indeed contain the missing dat file. I have checked that it is compatible with the existing dds file across printable chars* of the standard ASCII set. I see no reason not to include it with the 2.12 distribution. *except testing method using "inline" subtitles can't do double-quotes. And I didn't try whole set of Latin-1 chars. The bad news is that in doesn't solve any problems with stray pixels or poorly spaced characters, compared to scaling down from Stone 24pt. Artifacts were seen to the left of % C T W Y During test, characters were separated by two spaces, to isolate which char was causing an artifact. Nor did I see any visually discernible improvement or change in the rendering of characters. I was looking for any thickening of the thin parts of strokes, for instance. BTW, both Stone 24pt and now Stone 12 pt have weird stuff for ASCII "<" and ">". Maybe that's a TDM customization? The > replacement includes an artifact to right.
  25. Just thoughts for possible futures. No problem.
  • Create New...