Jump to content
The Dark Mod Forums

Geep

Member
  • Posts

    1064
  • Joined

  • Last visited

  • Days Won

    57

Geep last won the day on April 21

Geep had the most liked content!

Reputation

912 Legendary

5 Followers

Profile Information

  • Location
    Mid-Atlantic, US

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Stone 24pt Font Upgrade, May 20, 2024 Interim Release This second release is mainly concerned with providing accented upper-case characters, particularly in populating two rows of bitmap _1_. In summary - 31 capital letters now have proper accents. 5 other characters got minor improvements. As with the first release, this download has been double-checked with testSubtitlesANSI FM and is made up of - .dat and 2 .dds files, for distribution/game inclusion .ref [with changes annotated] and .xcf [master source GIMP project, including datBounds layers] 2024 May 20 Stone 24 Interim font update.zip Details of Improvements: This is likely the last interim release. The remaining work, leading to final release, involves a dozen more difficult cases, chiefly lower case, symbols, or Icelandic. Plus general spot cleanups.
  2. Certainly I intend the Stone 24 end product to be included in 2.13. As for the Interim(s), I'm posting them as "hit by a bus" insurance. It also gives anyone interested a chance to kick their tires in testing FMs. Or include them in 2.13 betas. Or in your Unofficial Patch. Enjoy.
  3. Stone 24pt Font Upgrade, May 9 2024 Interim Release This first release just clears away some of the low-hanging fruit, while buffing the new datBounds program. In summary - stray mark next to W removed poor spacing of J and AE improved 6 characters got accents added. The download is made up of: .dat and 2 .dds files, for distribution/game inclusion .ref [with changes annotated] and .xcf [master source GIMP project, including datBounds layers] 2024 May 9 Stone 24 Interim font update.zip The changes were also doubled-checked using the testSubtitlesANSI FM. As this work continues, with an interim release approximately monthly, characters to be fixed will be chosen seemingly "at random", but actually due to layout considerations... you don't want to know. They'll all be done eventually. Details of Improvements:
  4. Release of datBounds v 1.0 My new tool to visualize the font metrics in a .dat file is now available. For more, see https://wiki.thedarkmod.com/index.php?title=DatBounds I've been using this and testing it as I begin the long process of extending the Stone 24pt character set.
  5. It's true, there's no real place on the Wiki for menu customization... it relies on comments in the mainmenu_custom_defs.gui. So I'd guess I'd recommend you do a bug report, to either add a comment to that .gui file about it, or, if it's really a bug, fix it.
  6. I'm now considering the .xcf files as being in effect the source texture for the game fonts, at least those that have been bitmap edited in GIMP. So that's an argument for putting them in the TDM assets repo. But, in any event, they do need to be backed up somewhere official.
  7. That may be where @Amadeus got the folder provided to me earlier. Tels folder has - - .xcf files, not found in earlier work - for any given system font (stone, carleton, manon) and size(particularly 24 or 48), often more .tga/.dds files than earlier work (which originally had just ASCII characters). (You can open the files in GIMP to be even more definitive).
  8. Yep, moved on to greener pastures. BTW, what I quoted above from him will soon be untrue for Stone 24pt due to my upcoming bitmap surgery. Actually, the values in the current stone .dat file are already misaligned with what any archival font patcher script would produce, due to 2.12 tweaks with q3font & refont. I'll add a note to the wiki about this (explaining it better than here).
  9. Also, I've built another console app, "datBounds", to visualize the bounding box around each bitmap character. Starting from your choice of .dat, .fnt, or .ref file, it generates a set of .tga files, e.g., stone_0_24_bounds.tga & stone_1_24_bounds.tga. You can optionally include a 2-hex-digit label on each bounding box. More about that in May. I'm using the results of this to understand the current complex codepoint mapping of the Stone 24pt glyphs, and develop the workplan and grid layouts for upcoming work.
  10. Some good news! Tels dug around further in his old computers and found some gold. Namely, a whole fonts directory that includes GIMP .xcf files. Tels says: "The XCF files esp. are what I used to manually draw the new characters (like adding dots to an u to convert it to ΓΌ etc.) They contain many layers with different characters, that are layout exactly in the place where they need to be for the patcher script." That is, for english stone 24 pt, one .xcf file contains two independent RGBA bitmap layers, that can be saved separately as two .dds files. A quick glance of that content appears to match the current distributed stone_0_24.dds and stone_1_24.dds. So I won't need to back-convert from DDS to TGA after all. @Amadeus, I think a copy of this should be added to the TDM assets repository. Could you do that? * http://bloodgate.com/mirrors/tdm/pub/scripts/tdm_font_source.7z
  11. Also, related to font improvement, I've just released "ExportFontToDoom3All256", a reconstruction of an earlier but now lost tool variant. This is described and available in the wiki article ExportFontToDoom3 I tested that tool using one of the TDM FM fonts, Andrew Script, for which a TTF file is available. I generated a fresh set of bitmaps (newly including any available Latin-1 characters). I also mucked about with FontForge, to reconfigure that TTF to be ordered like the TDM custom codepage. However, Andrew Script is missing a fair number of Latin-1 glyphs, so it would take some work to make it good (whether by editing in FontForge or post-export as bitmaps). I'm putting that aside for now, since the jury is out on whether Western language support in FMs and their fonts will become viable (see Western language support in 2024?). Instead, I plan to turn my font-improvement-for-2.13 attention to Stone 24pt, which (because its used in HUD captions) is more clearly worthwhile to work on. Looks like I'll have to convert the Stone DDS to TGA as a prerequisite to bitmap editing.
  12. Just for the record to benefit readers here, the archived Stone .tga's turned out to be the original ASCII-only versions, not the versions that got extensive bitmap editing. Too bad.
  13. I agree, that is an issue. It would be better if the system handling briefings/readables could be revised as you indicated, to handle individual sentences as #str_, rather than whole pages. Baring that, having a key field like "#str_This is a whole page\nfull of text that goes on and on and on [...] until done" would appear as a very long single line. That is nasty to look at in the Readables Editor, and even worse in the .langs file, where the too-long text would appear twice on a line (once with #str_ prefix of English version, another in translation). So for those, it would be better in the short term to stick to symbolic keys, e.g., existing #str_12345 or revised form #str_myfm_book_of_spells_page_1 I might add, in the longer term, enhancing the Readable Editor to use the .lang files would be an enormous improvement for FM authors and a significant accomplishment. A fair amount of work though, but probably doable in increments over several releases.
  14. I think you need to do things at the exact moment in DR that the user changes a field, so you can capture both the old value and the new value. Would be way better if DR just handled everything natively, but could be done through a hook to an external script too, I suppose. Or some complicated logging.
  15. One of the problems with the old #str_number system, that would not be automatically solved in the new #str_phrase system, is lack of versioning/history. For example, suppose in the FM I provide a new string: #str_Mother! which (by magic TBD, ideally in DR) generates this placeholder in all the .lang files: "#str_Mother!" "Mother!" The translator in the fr.lang file later does this: "#str_Mother!" "Mere!" Still later, the FM author revises the string in DR: "str_Mother!!!" In a naive implementation, this breaks the link to the existing translation(s), which becomes orphan in all the .langs, and creates a new entry: "#str_Mother!!!" "Mother!!!" OK, how could we do better? Case 1 (as above): the FM author knows the change is trivial, and so (at revision time in DR) might ask the translations to be retained but marked for review. So maybe the fr.lang files gets: // WAS UNTIL 2025-01-01: "#str_Mother!" "Mere!" "#str_Mother!!!" "Mere!" // Needs minor review with removal of the orphans (after they become comments and moved to before their replacements) Case 2, where the revision is not trivial: the FM author (at revision time in DR) might ask the translations to be replaced by english but marked for review, e.g.: #str_Mother of Pearl! causes the fr.lang files to have (with orphan removal as case 1): // WAS UNTIL 2025-01-01: "#str_Mother!" "Mere!" "#str_Mother of Pearl!" "Mother of Pearl!" // NEEDS REDO Then the translator could eventually fix it: // WAS UNTIL 2025-01-01: "#str_Mother!" "Mere!" "#str_Mother of Pearl!" "Nacre!" // Done 2025-03-14 by Henri
×
×
  • Create New...