Jump to content
The Dark Mod Forums

Geep

Member
  • Posts

    1032
  • Joined

  • Last visited

  • Days Won

    55

Everything posted by Geep

  1. This was overall an enjoyable FM for me. Thanks for making it. Thoughts/spoilers: Also, there were 2 minor issues undoubtedly due to engine or asset shortcomings:
  2. That would be another good method. The one I used was easier for me, given that I was also supporting a SFW difficulty level where she is already dressed before reaching the attic. Thanks. No animation available for that either, so all done with cut-scene fakery and video editing. Glad you enjoyed a bit of sparks with those. Although I can't take any credit for the idea of dress mannequins with human hands... you'll see them IRL at any mall. But the implementation in TDM... therein the magic: It's 11pm here, and I'm off. Thanks for chatting.
  3. That "fall" delay was by design. Because there is no animation available to show her actually re-dressing from the trunk of clothing, so instead I wanted you to have to imagine it. Rather than actually catching up with her and seeing the instant body swap.
  4. They are a riff on historic mushroom-style "linen smoothers", as this article sketches: http://www.oldandinteresting.com/antique-irons-smoothers-mangles.aspx The gold color hints at heavy brass. Bonus in the NSFW difficulty setting: One is also seen outside a laundry setting, for its *snort* suggestive shape.
  5. I have just released a new utility, "refont", as an open-source, partial-successor of the traditional "q3font", used to tweak the spacing and placement of TDM's bitmap font characters. For the whole story, see the new wiki page Refont.
  6. I have just released a new utility, "refont", as an open-source, partial-successor of the traditional "q3font". For the whole story, see the new wiki page Refont. (I'm gonna post this in a few forum threads. Don't hate me for that.)
  7. I have just released a new utility, "refont", as an open-source, partial-successor of the traditional "q3font". For the whole story, see the new wiki page Refont.
  8. Yeah, it's J anky, but can't be fixed in the DAT file. Likely it requires moving pixels in the bitmap. I'm personally unenthused about doing that, particularly in a 2.12 timeframe.
  9. Yet another Stone 24 pt Update. This removes stray marks to the left of G (as well as char 249, u with accent grave), visible with textscale 0.25 but not 0.24. So this may or may not benefit subtitles, but it will definitely help Stone font readables. Most of them use a scale of 0.25 for body text. An attempt was made to also improve G spacing, but (since xSkip can't be changed) effect is marginal at best. fontImage_24.dat of Feb 27
  10. OK, I poked around a little further. At the moment, beta5 is what I have installed. testSubtitlesANSI ships with an override of tdm_subtitles_message.gui, which allows easy adjustment of textscale. The shipped textscale is set to 0.24. With that, the stray marks left of G are not visible. If you change it to 0.25, they are visible; which is evidently what your custom gui is also using. If you setaside any custom tdm_subtitles_message.gui, then the core one goes into effect. Which, for beta 5, uses a textscale of 0.24 I don't know whether we will be going with 0.24 or 0.25 for the release. Nevertheless, now that I can see the stray marks, I'll see about fixing them. BTW, with your gui, the black outline shadows have the effect of enlarging the stray marks as black smudges. Helpful for diagnosis.
  11. I just looked at capital G. I didn't see any stray marks. The spacing to its right was a bit larger than required, but I didn't think grossly so. Is that what you were referring to?
  12. Here is the release of testSubtitlesANSI , one of my tools to test and improve the Stone 24 pt font that is used in all the English subtitles. testSubtitlesANSI.pk4 of Feb 25, 2024 As the screenshot below reveals, this testing tool is an FM that's a variant of that used to develop subtitles for individual AIs. Here, the subtitles are just alphabetic lists. There are 7 subtitles that cover all the TDM 8-bit codepoints (e.g., 0-255), including those representing European languages. The first two subtitles (i.e., codepoint sub-ranges) are shown in this screen shot. The tool allows inspection for stray marks and inter-character spacing; black walls & floor facilitate that. This release includes the most recent improvement to these attributes, provided in yesterday's update of the fontimage_24.dat file. (The changing of those attributes was done with a different tool, used iteratively with this one.)
  13. Oops, in that last release, I accidentally didn't check character spacing in the codepoint range 128-159. And sure enough, there were problems with character 131 & 132, which needed 4 more pixels of horizontal box shifting than the 3 pixels they got earlier. So here's a better version: fontimage_24.dat of Feb 24
  14. Here is another update to the English Stone font's DAT file used for subtitles and some readables: fontImage_24.dat This supercedes the Jan 30th update. As agreed, now all character spacings - as given by xSkip - are preserved (from this file in TDM 2.11). Exception: the Jan 30th repair of garbage metadata for "<" and ">" remains, including xSkip repair. ASCII Characters (lower 128). The earlier Jan 30th post summaries those ASCII characters that needed metadata changes to avoid adjoining stray marks. (The detail report below updates newer reversions and minor revisions.) ANSI Characters (upper 128). An analysis was also made of the status of the Stone 28 pt font's characters in the upper codepoint range of 128-255. This could be of interest if the subtitle system was some day expanded to include European languages, and continues to use the historic codepage method. The analysis also prompted some additional DAT tweaks now. Broadly, implementation of the upper-range characters (standard or TDM-specific, as defined in the TDM wiki's I18N - Character mapping I18N) is incomplete for Stone 24 pt. The status is: 43% (55 chars) Good as is. 9% (12 chars) Good enough after DAT tweak included in this update. 6% (7 chars) Missing and shown as hollow box. 30% (38 chars) Missing accent/diacritic. 7% (9 chars) Otherwise weird. But often suggestive of glyph work started but not completed. In addition, 7 chars within categories (3-5) were "improved", but are still not good. To really solve categories (3-5) requires DSS bitmap surgery (and corresponding DAT adjustments), which is beyond the scope of planned work. DAT tweaks of ANSI characters (like with ASCII) were careful to avoid changes to xSkip. Tweaks can be further grouped by problem solved.... In category (2): - (4 chars) Char is clipped, with stray mark from adjoining character on other side. - (7 chars) Stray mark, without char clipping. As improvements in categories (3-5): - (3 chars) Stray mark, without char clipping - (4 chars) Out of valid range on top edge A categorized itemization about treatment of specific problems and characters, with further details, is here: Information about methods, including new tools, to conduct this analysis and tweaking will be forthcoming, mostly after the 2.12 release.
  15. It's hard. I see what you are thinking about is a "bullet point" pattern, with or without a bullet point character. For that case, I suppose what we are trying to detect is: - the line starts with the bullet point pattern - a "J" character (say) with a shortened spacing, is somewhere in the line. - the line itself in the xd file is long enough to force a word wrap (let's just think about a single wrapping here) - the author assumed a particular word wrap point, and put in extra spaces in mid-line, immediately at the wrap point, so as to indent the latter part of the line, aligning with the indent of the first part. - the shortened-spacing J screws up the resulting alignment. Probably would need a script/program to winnow this down... ideally, that algorithm could also restrict attention to just Stone font. I'm OK with putting such an effort off for now, maybe revisiting it for 2.13.
  16. 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.
  17. 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.
  18. 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
  19. 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.
  20. 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.
  21. 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.
  22. 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.)
  23. 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.
  24. 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%
  25. Maybe it would be possible for the user to just bind a hotkey to toggle subtitles on/off?
×
×
  • Create New...