Search the Community

This last month, I've been exploring TDM's font situation, and improving the documentation as I go. In the wiki, "Font Conversion & Repair" was rewritten, with parts broken out and expanded as: Font Files Font Metrics & DAT File Format Font Bitmaps in DDS Files ExportFontToDoom3 Q3Font Refont As announced earlier, that last item is a new C++ console utility for revising font metrics in DAT files; essentially another alternative to Q3Font and Font Patcher. It now has additional functionality that provides font-coverage analysis. A summary of current results across all TDM fonts is reported in the forum thread "Analysis of 2.12 TDM Fonts". Also, refont allows its human-readable outputs to be decorated with an annotation for each character (out of 256 codepoints). Associated with that, I've just created and released 4 annotation files: 1 Cyrillic version for TDM's russian map 3 variants for TDM's custom english/european char map. One of the variants was derived from another new mapping file that is now available from existing wiki article "I18N - Charset". Within that file is a list, in a standard format, of the 256 TDM bitmap codepoints mapped to the corresponding Unicode U+NNNN value and name. This may be useful in defining TDM's mapping to TTF font editing programs. For all these wiki pages mentioned, I imagine there will be additional cross-links and tweaks. But pretty much done.

Obviously the change will only work in last night's dev snapshot and onward. But missions can already start implementing this: It's just that older TDM versions won't see the debrief screen and only future players or dev users will enjoy them.

Well, the 7600 XT is considered sus for putting 16 GB on 128-bit, but it clearly works in some scenarios. Also IIRC GDDR7 will have about +30% bandwidth over GDDR6X right out of the gate, rising to about +100% as the generation progresses. Big caches (Infinity Cache L3 for AMD, lots of L2 for Nvidia) have made smaller bus widths more viable, and I think they have improved compression techniques and other factors over time to help alleviate bandwidth demands. There's already a little bit of analysis of what we can expect to see in RDNA3+ and RDNA4, very technical though: https://chipsandcheese.com/2024/02/04/amd-rdna-3-5s-llvm-changes/ I am eager to see if AMD is bold enough to do (or allow AIBs to put) 32 GB on the top RDNA4 card, which has long been rumored to be slower than the 7900 XTX in raster, but will hopefully beat it in raytracing and other areas such as AI/ML perf. And I think that card will have a 256-bit bus and 16 GB memory normally.

@The Black Arrow That's a good analysis. I don't disagree but we're referring to different time periods with different quality aims: In the early days of 3D and low-res CRT screens when we had 256x256 textures, detail textures were used to make surfaces appear as if they have 1024x1024 textures... today in the age of 1080p monitors such texture can appear blurry from up close, we want to make 1024x1024 textures appear of 4096x4096 quality. Back then the goal was to get at least a little bit of perceived sharpness, today the goal is to see those microscopic details on every surface as if everything is real... while the concept of detail textures is old it scales to cover both aims. As you correctly pointed out, the ideal solution would be upgrading the actual textures themselves. Sadly there are two big problems with this that will likely never be possible to overcome: Someone must create or find identical textures to replace existing ones, which have to retroactively fit every old FM. That would be a huge effort for so many images, and will not look exactly the same way so people would complain how "this wall used to be made of small red bricks which are now larger and yellower which isn't what I intended and no longer line up". An advanced upscaling filter may be able to bump the resolution with good results, this would be a lot less effort and retain the exact appearance of textures. The even greater issue is storage and memory use would go through the roof. Imagine all our textures (from surfaces to entity skins) being 4096x4096 which would be the aim for decent quality today: TDM could take over 100 GB of drive space, you'd need at least 16 GB of RAM to run it, and the loading time of a FM will be 5 minutes. Detail textures are a magic solution for both problems: They're overlayed in realtime on top of the standard textures without changing their base appearance. This means you see pixels several times the scale of the image without requiring any image to actually be at that resolution, no vRAM or loading time increase. And if detail layers are disabled with distance you also don't lose FPS in per-pixels calculations when distant lights update.

yeah its a jungle out there but a 12 gb card on a 128 bit bus would only be viable with dlss and then only just . but there will probably be plenty of options as you mention though id still go for something that would atleast be able to drag the ammount of vram without workarounds. strangely the old amd R9 390 had a 512 bit bus and could probably have accepted 32 gb vram but the card is to slow to do 4k in modern titles. even so the 8 gb model actually ran quite nicely in games such as the first horizon in 4K but would probably choke and die on forbidden west . minor wtf moment is crysis remastered it runs it at 4k in can it run crysis with a gazillion fps looks quite purty to but i suspect this is a bug.

Alright, so, I'm a Texture Artist myself for more than 20 years, which means I know what I'm talking about, but my word isn't law at all, remember that. I've worked (mostly as mods, I am a professional but I much prefer being a freelance) with old DX8 games up to DX12. When it comes to Detail Textures, for my workflow, I never ever use it except rarely when it's actually good (which, I emphasize on "rarely"). This is one reason I thought mentioning that I worked with DX8 was logical. One of the few times it's good is when you make a game that can't have textures higher than what would be average today, such as, World Textures at 1024x1024. Making detail textures for ANY (World, Model) textures that are lower than 128x128 is generally appealable. Another is when the game has no other, much better options for texturing, such as Normal Maps and Parallax Mapping. Personally, I think having Detail Textures for The Dark Mod is arguably pointless. I know TDM never had a model and texture update since 2010 or so, but most textures do seem to at least be 1024x1024, if there's any world texture that's lower than 256x256, I might understand the need of Detail Textures. Now, if this was a game meant to be made in 2024 with 2020+ standards, I would say that we should not care about the "strain" high resolution textures add, however, I do have a better proposition: Mipmaps. There are many games, mostly old than new ones, that use mipmaps not just for its general purpose but also to act as a "downscaler". With that in mind, you boys can add a "Texture Resolution" option that goes from Low to High, or even Lowest to Highest. As an example, we can add a 2048x2048 (or even 4096x4096) world texture that, if set to Lowest, it would use the smallest Mipmap the texture was made with, which depends on how the artist did it, could be a multiplication of 1x1 or 4x4. One problem with this is that, while it will help in the game with people who have less VRAM than usual these days, it won't help with the size. 4096x4096 is 4096x4096, that's about 32mb compressed with DXT1 (which is not something TDM can use, DXT is for DirectX, sadly I do not know how OpenGL compresses its textures). I would much rather prefer the option to have better, baked Normal Maps as well as Parallax Mapping for the World Textures. I'm still okay with Detail Textures, I doubt this will add anything negative to the game or engine, very sure the code will also be simple enough it will probably only add 0.001ms for the loading times, or even none at all. But I would also like it as an option, just like how Half-Life has it, so I'm glad you mentioned that. But yet again, I much prefer better Normal Maps and Parallax Mapping than any Detail Textures. On another note...Wasn't Doom 3, also, one of the first games that started using Baked Normal Maps?

Is it already possible to pass information from the briefing to the mission? I don't think I ever saw this implemented apart from the starter-location selection. TDM is currelently in early dev, maybe a bit soon to start implementing in missions? I think it's better to wait for beta, so no changes will be done to the system.

Greatly enjoyed the moment of starting the mission and hearing the Beethoven's symphony. Well fit for the atmosphere of the game and provided the mood for the FM as well. I found acting against my own will by shutting off the music.

I agree! I never even noticed that there was a title there. I will include this in my patch until it's included in core...

Interesting! Does it update all default textures so it's used on everything in the world? I should replay it and check that out: It would give us a good view of how the effect will feel in practice. Looking at the page, they seem to do it the conventional way I was thinking of trying out, which is currently supported by the engine but more limited than a proper implementation. It also looks like they're only doing it for the albedo channel, to be effective detail should be applied to all maps... the normal map is where the improvement should be most noticeable as it responds to lighting and modifies everything else. The implementation I'm thinking of should be universal like all effects and work on any FM new and old. It would be controlled by a menu setting, no one needs to enable it if they don't like how it looks or it impacts performance. Each detail pass should fade and be hidden with distance, we don't want to stress pixel lighting by having it compute thousands of dots on distant surfaces each frame. Just like the TDM ambient method, we'll likely need a special segment for materials meant to indicate what kind of detail each texture wants, then based on settings and camera position the renderer must modify each surface accordingly.

There's been talk over the years on how we could improve texture quality, often to no avail as it requires new high-resolution replacements that need to be created and will look different and add a strain on system resources. The sharpness post-process filter was supposed to improve that, but even with it you see ugly blurry pixels on any nearby surface. Yet there is a way, a highly efficient technique used by some engines in the 90's notably the first Unreal engine, and as it did wonders then it can still do so today: Detail textures. Base concept: You have a grayscale pattern for various surfaces, such as metal scratches or the waves of polished wood or the stucco of a rough rock, usually only a few highly generic patterns are needed. Each pattern is overlayed on top of corresponding textures several times, every iteration at a smaller... as with model LOD smaller iterations fade with camera distance as to not waste resources, the closer you get the more detail you see. This does wonders in making any texture look much sharper without changing the resolution of the original image, and because the final mixture is unique you don't perceive any repetitiveness! Here's a good resource from UE5 which seems to support them to this day: https://dev.epicgames.com/documentation/en-us/unreal-engine/adding-detail-textures-to-unreal-engine-materials Who else agrees this is something we can use and would greatly improve graphical fidelity? No one's ever going to replace every texture with a higher resolution version in vanilla TDM; Without this technique we'll always be stuck with early 2000's graphics, with it we have a magic way of making it look close to AAA games today! Imagine being able to see all those fine scratches on a guard's helmet as light shines on it, the thousands of little holes on a brick, the waves of wood as you lean into a table... all without even losing much performance nor a considerable increase in the size of game data. It's like the best deal one could hope for! The idTech 4 material system should already have what we need, namely the ability to mix any textures at independent sizes; Unlike the old days when only a diffuse texture was used, the pattern would now need to be applied to both albedo / specular / normal maps, to my knowledge there are shader keywords to combine each. Needless to say it would require editing every single material to specify its detail texture with a base scale and rotation: It would be painful but doable with a text injection script... I made a bash script to add cubemap reflections once, if it were worth it I could try adapting it to inject the base notation for details. A few changes will be needed of course: Details must be controlled by a main menu setting activating this system and specifying the level of detail, materials properties can't be controlled by cvars. Ultimately we may need to overlay them in realtime, rather than permanently modifying every material at load time which may have a bigger performance impact; We want each iteration to fade with distance and only appear a certain length from the camera, the effect will cause per-pixel lighting to have to render more detail per light - surface interaction so we'll need to control the pixel density.

You were on to something with that, but TDM won't let atdm:ai_base use another class's aas file. I changed tactics and switched it to atdm:steambot_base instead (it also happens to be the only AI base that doesn't say "do not use"). Dmap auto-generates the associated aas file (aas96) so there is no warning when the player starts. More importantly, it actually still works! So my AI will now follow the player with no errors or warnings.

I would like to recommend adding "Warning: Skin names cannot start with numbers, as it will cause models to appear black in-game."

Hint: I checked the objectives. It is possible to not read the note and also not see the body, in which case you wouldn't know she needed reviving and then you would not be able to complete the mission. I will release an update to fix that. Since you did find her though, I don't know why you didn't get an objective to revive her. I'm not able to reproduce that bug. Finding the note is set as optional, so missing that alone wont cause a fail.

Just type the @ character, and then the first character of username (for example ‘k’ for kingsal). That will bring up an autocomplete list of users starting with that character. Keep typing, or pick the user from the list

Ooohhhhhh, it's twitching in the build intenstine, as we say in Sweden (or do we? :D) I'm quite eager to create something. But they're releasing new skaven models for Age of Sigmar 4 this summer... And I have a 2 year old... And work... And a girlfriend... And too little time... I will try to create something at least. If I run out of time, I'll run out of time; then I at least have built something that can be released after the contest... Count me in, with the caveat that I may pull out before deadline...!

Yes. Sure, I will change it, but I do mind. In addition to changing the forum title, I have also had the name of the pk4 changed in the mission downloader and the thiefguild.com site’s named changed. It's not just some "joke". The forum post and thread are intended to be a natural extension of the mission’s story, a concept that is already SUPER derivative of almost any haunted media story or most vaguely creepy things written on the internet in the past 10 or 15 years. Given your familiarity with myhouse.wad, you also can clearly engage with something like that on some conceptual level. Just not here on our forums? We can host several unhinged racist tirades in the off-topic section but can’t handle creepypasta without including an advisory the monsters aren’t actually under the bed? (Are they though?) I am also trying to keep an open mind, but I am not really feeling your implication that using a missing person as a framing of a work of fiction is somehow disrespectful to people who are actually gone. I have no idea as even a mediocre creative person what to say to that or why I need to be responsible for making sure nobody potentially believes some creative work I am involved in, or how that is even achievable in the first place. Anyway, apologies for the bummer. That part wasn’t intentional. I am still here. I will also clarify that while I love the game, I never got the biggest house in animal crossing either. In the end Tom Nook took even my last shiny coin.

I don't really know what this is about, but I will use the occasion to remind everybody that there is a surplus pixel at the lower left side of the capital W character. People speculated this might come from another character nearby in a font table but I don't see how V could have a pixel at that position....

I'm honestly not sure, it's a race condition maybe? I found and fixed 2 different segfaults (PR is here), one relating to threading and the other one relating to a variable being referenced after it was cleared out. This stops the skin editor from crashing, but it seems there are still a lot of usability issues. I'm not sure if they are all Linux only, but here's what I found: The rename operation happens every time you type a character, which is a little laggy. It would be better to rename it when you are done typing and the field loses focus Typing new characters while renaming works as expected, but deleting characters causes the box to highlight so you have to reset the cursor before deleting another one. On the Material Replacements tab, click to edit is not working for me. I spent a lot of time on this, I can get a box to show up if I replace the editbox+button with a simple edit box. I think it's related to the compound control not being able to have focus. The skin name is showing up on top of the Close button This will require more wxWidget-fu than I have time to do right now.

I have updated my Refont program, to now have a function that can analyze a font DAT file for missing or problematic characters. As part of a broader inquiry, I've just applied that program, individually, to all current 'english' font DAT files. I'm reporting the overall results here. I'm sure this will not be a surprise to some of you, but may be to others. Background As you know, TDM fonts are based a bitmap system, derived from 256-character code pages, of which "English" and "Russian" are currently supported. "English" is actually Latin-1, with additional characters to cover more European languages in a single codepage. This is (in theory) quite good for major European languages, less so for less-prominent ones. For each font, bitmaps are distributed in 3 sizes (12, 24, 48 pt), with the engine doing interpolation scaling. Current Font Findings 12-pt Size for All Fonts Only ASCII (i.e., lower range 0-127) characters are provided, no European. For some fonts (stone, mason, mason_glow), the 12-pt DAT is not distributed, so the engine will substitute a larger size, which typically has better Latin-1 coverage. For Fonts Used in Main Menus, HUD, or Subtitles The numbers shown approximate the number of "characters needing work" Fontname Size-24 Size-48 carleton 20 16 carleton_condensed 20 35 mason -- 33 Since 24 pt is not distributed, engine uses 48 pt. stone 30 83 For Additional Fonts Used in FM Readables, Etc. Except for one font (treasure_map), all the remaining fonts are ASCII-only, i.e., no characters in the upper range. In the lower range, routinely the 24 and 48 pt sizes have equivalent coverage. Most of these fonts are fully or nearly complete, while some neglect certain punctuation symbols. The worst is "everette", with 24 "needing work" characters. Further details are here:

I havent tried in 2.11 yet but I will. Just an update on this. For now I think I fixed it by: - Addressing most of the warning in the log above. Outside common errors like some missing textures and such that are part of the core. - Made sure to give my parallel lights "parallelSky " "1" spawnarg. - Deleted my .aas files and rebuilt them - Dmapped the entire thing Right now I am not getting the load error . It's a very hard problem to nail down because the console isn't giving a specific script name that it's getting hung up on (if that is even the issue similar to Amadeus's problem) AND I am actively working on the mission, creating new errors, fixing other broken things. ect. Its definitely something I fear will pop back up in beta testing though

It is possible. You can drag outside a selected speaker and resize it exactly like a brush. Note that you have to drag outside the entire bounding box of the speaker (as if it were a rectangle), rather than just outside the circular boundary, which isn't particular intuitive. If you enable View -> Show -> Show Size Info you will see sizing axes which give a better idea of where the bounding box is.

I also take it the skin editor isn't among the most used parts of DarkRadiant, making this less easy to spot. Hopefully now the team will notice the issue, and it's ideally nothing hard to fix since DR has a history of GUI issues like this that stabilized.

Me too. Also the other FMs which were released on the 1st of April. Not a fan of speedruns, so, that optional objective will be just ignored.

Oh you mean the bug on the loot screen? No matter what I did, it wouldn't go away. But there's no need to worry, it's just a floating point precision issue and it can't hurt anyone, ha ha No problem. Upon the receipt of the cashier's check, the guide will be sent to your house within 10 business days. Thank you.