stgatilov

I have started looking into it. But I'm afraid the original shader makes much more sense to me, so I will update it to use a cube map.

Any program or game can bring any PC to its knees by setting something higher than it makes sense. And wasting more power does not necessarily means the visual look becomes much better. Modern games tend to limit configurability to avoid this, e.g. providing "low/medium/high" presets (sometimes even without individual settings). Here is one particular story. When TDM 2.06 came out, the soft shadows had "Extreme" setting. However, most players set this setting to max value, only to learn that their PC cannot handle it. So we decided to remove it from the menu But even "Very High" setting can be quite punishing for GPU depending on circumstances. Aside from that, there are many different FMs in TDM created by many different people across 10+ years. Some of the FMs are very modest in performance requirements, while some of them have many lights and are quite slow even with medium settings and good PC. All of this is up to the author: they can also make their FM waste any PC if they are not careful. There are even some famous places which are known to waste processing power. For instance: NHAT cave with its sick stalagmytes eating CPU; Right Properly which has a large street section with many lights and guards. The bottom line: while your PC is definitely stronger than what most players have, you won't be able to play everything effortlessly if you set ALL to max. I guess the most slowdown usually comes from soft shadows quality and antialiasing. Also check that Render Scale displays 1 and not higher. High resolution (aka 4K) also increases GPU load 4x times, in which case it probably makes sense to reduce Render Scale to something like 50% Of course, this may be some sort of issue as well. But better report some specific case then.

Isn't it too large to provide an objective? It is probably possible to say "find every weapon and tool", but such objective might be hard to finish and is boring since it has no plot behind it. When I was playing it, I put myself an objective "look behind every door in starting room to get familiar with features". Later I realized that there are whole sections of the maps which I did not see

Isn't it why New Job FM was created?

Thank you! I can reproduce the crash on mill8. It crashes when freeing BSP tree in AAS build I'm afraid it will need some time UPDATE: This is not the first time when dmap crashes at this place. It is due do to numeric problems. By the way, I don't think it is a regression actually: numeric behavior of dmap has changed, so such issues can disappear or appear on complicated maps.

Well, it does not sound like a crash. Although I don't remember: does modern Windows 10 shows the dialog on crash by default? How did you get console dump? Perhaps you could enable logFile as described here? If TDM closes without a pause, then this is the only way to know the whole console output for sure. Thank you for doing this! I would be happy to know too what goes wrong, especially if this is a regression from 2.07. That's your choice. Just keep in mind that there is a chance that the bug (if this is a bug) will get into final release without your attention By the way, it seems we didn't even try the easiest way to analyze the problem. As far as I understand, you can reproduce the problem perfectly on 2.08. Could you please send me the FM/map where you have the problem? I'll try to dmap it myself, and it would be much faster and easier to understand what's going on if it reproduces.

Unfortunately, it is usually some minor changes which should not break anything but still break. We have just finished migration from ARB, and thank god there were no custom shaders (well there was one, but its absence would go unnoticed even if we did not convert it). Yes, this is what I think too. Now it seems to be in prototype phase, but if it shows no issues and is popular, then it's better to integrate it directly into the engine. After a good enough design proposal, of course.

I'm afraid the dump does not contain crash. It looks like it is a dump of running TDM, probably with main menu or console open. The last console command was "dmap mill7", but probably it finished. Are you sure you are meaning "crash", i.e. you see OS message about it and the TDM program terminates completely immediately after you click OK? If yes, maybe you captured the dump at the wrong moment? Normally, you should record dump after it has crashed, when the OS message is still shown.

Given that there is a discussion about interior mapping, I'd like to return to the question of maintenance of custom GLSL shaders. Right now I see choices: Do not allow mappers to write custom GLSL. Allow writing custom GLSL and promise their maintenance. And as a consequence, most likely lock GLSL version forever?... Allow writing custom GLSL but warn that they can get broken during future engine updates.

I don' think log contains anything about the crash. The only proper way to know what is crashing is to record a crashdump and share it to one of the coders.

See p.2 and p.3 in the Mapping section of changelog, they provide a link to wiki. Ok. If someone can reliably reproduce the problem with fonts, please provide darkmod.cfg and exact steps.

Hmm... you cannot imagine how much software works on OpenGL. As for now, all those vendors would more likely drop support for Vulkan, calling it a "failure", than drop support for OpenGL

beta208-03 has been released. The list of changes is provided in its usual place. Remember that you must download tdm_mirrors.txt again from the link in the original post before running tdm_update. Otherwise you will not get the new beta release and will stay on beta208-02 instead.

It is also worth trying r_cinematic_legacyRoq 1 --- that would enable original Doom 3 code for ROQ playback, instead of FFmpeg. To be honest, I regret now that I finished FFmpeg playback. It was probably a better idea either to extend ROQ or to take some particular format like ogg+vorbis+theora and support them by using official libraries from Xiph.org instead of FFmpeg. Or mkv+webm+opus, which is another free combo. Now the djinn is out of the bottle, and FFmpeg will stay with us forever.

No, it is not locked at 60 FPS, it is bounded below at 60 FPS. Higher-FPS physics are allowed, since otherwise the game would not run smooth on high-FPS monitor.

1 millisecond is way tooo small! It should be something like 500 ms, or otherwise there must be some proper handling for timeout

Do you have the file {darkmod-root-dir}/newjob/newjob.pk4 ? Of course, the {darkmod-root-dir} is the place where you installed TDM to. Anyway, if you decide to reinstall TDM please do one of the following: Install TDM not to Program Files. Basically, find some directory where you can add/edit files without UAC prompt, and install TDM there. Use installer suggested by Freyk, it contains additional workaround for setting permissions. A simpler solution would be to forbid running tdm_update with elevated rights, or forbid installing TDM to Program Files. Having TDM in Program Files is a way to shoot yourself in the foot.

Everyone here, and especially people who had problems with aliased font. Could you please verify that r_useFBO is 1, and set it if it is not? I have seen cases when some errors reset it to 0, and it is never returned back.

If someone suspects that packaging dropped a file, please report either a file path (like models/md5/chars/monsters/werebeast/werebeast_mesh.md5mesh) or an in-game asset path (like textures/darkmod/fogs/real_fog_layer_moving). Regarding werebeast, I see the following files with "werebeast" in their name in latest beta package (ignore the numbers): Almost all of these files are in tdm_ai_humanoid_beasts01.pk4 archive, which is new. So check at least that it is present. If it is not, then run game and verify that you see proper svn revision in game console (that's the last number in the lower-right corner of the console). Finally, please verify that you have the following in tdm_mirrors.txt file (NOTE: latest beta is beta208-02, the last digit must be "two"): [Mirror localhost] url = http://tdmcdn.azureedge.net/beta208-02 weight = 1 Note that unlike previous betas, this time you must redownload tdm_mirrors.txt every time you want to get a new beta package. The link to this text file is given at the very first post, and I will update the underlying file every time a new beta version comes out.

Please keep in mind that playing a video takes a lot of resources. You might be OK with one such video on a test scene, but if you start filling FM with them, you will have performance problems quickly. Having 10 videos is like opening 10 VLC at the same time. EDIT: Moreover, I believe I never tested more than one video playing simultaneously... ever. Given that every such playback runs on several CPU threads with synchronization, nobody knows what could happen.

It is possible to compress on CPU with SSE/AVX. Uploading a texture takes time anyway, so texture streaming usually goes through some sort of async stuff like PBO, to avoid locking main thread. As far as I remember the game did not block or lag, it just showed low-resolution textures when you rotate camera (although I did not notice it when I played, perhaps I tweaked some config to avoid the issue). That's why the best idea is to start loading assets beforehand, so that you can show them in full glory when the time comes. All those delay-loading techniques will inevitably cause popping.

Yeah, looking at this all is a bit sad, especially when you compare idStudio to Radiant. Although looking closer, it seems that they did not drop their old habits completely... like if some of this is still rooted in idTech4 and earlier. I wonder if this engine still uses brushes Nothing yet made me think otherwise: they can still use brushes for basic level structure, and then use it for high-level culling. They showed editing geometric detail in realtime, but it does not contradict anything. The brushes can be used only for large hard walls, but they did not show realtime editing of map layout on global scale. Why not? It is possible to start loading and decoding jpg file prematurely in background, and then drop it from memory when you are far away from it (or based on other criteria). It is of course less efficient than taking raw texture data and pushing it to GPU. And it is hard to do any LOD, since the whole image must be kept in memory.

Gamma/brightness has been merged into postprocessing pipeline, which somewhat reduces the effects of gamma correction (probably to avoid overbrightening). Previously I heard that gamma = 1.2 is sort of default, so I set it as default value (with gamma = brightness = 1 the game is obviously too dark). But new gamma = 1.2 is a bit darker than old gamma = 1.2 To be honest, I came to conclusion that I should adjust gamma every time depending on circumstances. Am I playing or only testing? How strong is ambient light? Is it morning or evening in the real world? etc. Previously it was too painful to use non-default gamma, because desktop was messed up after a crash, but now everything is OK.

Did you check that all values are set correctly?

I guess current code integrates only with X system. Most likely there is no code to cooperate with Wayland. I'm not familiar with this side of Linux, but is it possible to somehow force using X system just like NVIDIA drivers did?