stgatilov

One thing I don't understand is why Max FPS has so many options. I'd say in such case it should better be a slider with value, like e.g. gamma slider. P.S. Meanwhile, I'm trying to write more tooltips and update existing ones...

Except that it is vice versa: with uncapped FPS physics runs with rendering and the results of modelling somewhat depends on your FPS, whereas with old-style model physics always works at 60 Hz frequency, not depending on graphics.

I think the main reason is that internally there is huge difference between the two modes (Uncapped FPS: yes or no). Up to the point that "Uncapped FPS" mode has been considered experimental for many releases. I don't remember when we last had a problem with it, but we always wanted to have a way to switch it off, and doing so on "Max FPS = 60" is almost the same as not providing any way to configure it in the main menu at all. Another thing is that "Max FPS" was not intended to exist initially, uncapped FPS should just work as fast as it can. But then we noticed that high FPS causes issues (e.g. some sounds disappearing), and we did not manage to fix it properly. We just put a "sane" limit of 166 FPS, since that felt the safest way. Then came people with high-frequency monitors, and they wanted to change this limit to a bit higher that their monitor frequency. At the end someone decided it is important enough for everyone and added it to menu settings. It seems to me that people with high-frequency monitors can live well with both Uncapped FPS and V-sync on, without the need to tweak the FPS limit which was never intended to be visible to end user. If yes, then we can remove "Max FPS" from the menu.

Applied p.1 in svn rev 9780.

It is not too late if someone is brave enough to update all corresponding missions. But it has to be done during beta phase.

I think these two lack tooltip. The tooltip for Uncap FPS should say that this mode allows FPS higher than 60.

Here is how cloudscroll works on fresh SVN (with all kinds of clamp-to-zero present in fragment shader): The volumetric light and r_showLights 4 show the light frustum. You can easily see that floor is lit outside light volume, sometimes pretty far outside, and with ugly scissoring. If we clamp texcoords before applying texture matrix, then the light will always be inside frustum. UPDATE: See it yourself on test/volumetric_light_shadows.map.

If a triangle (e.g. a large one) passes all frontend tests against light volume, then it is sent for actual rendering. Shader computes texcoords and fetches the textures even for fragment outside light volume, it has no way to distinguish. If both texture fetches return non-zero, then fragment outside light volume gets lit. The check that I introduced forces clamp-to-zero rule on both textures, so this issue does not happen... unless a nontrivial texture matrix is used (I simply did not think about texture matrix when I implemented it). Imagine that texture matrix shifts U parameter by 0.5. If a fragment has texcoords (-0.3, 0.5) without texture matrix, then it will have texcoords (0.2, 0.5) with texture matrix, so this fragment will be lit despite it being outside light volume. And this can easily happen for point light as well. The most reliable fix is to pass light volume matrix and texture matrices separately, and apply clamp-to-zero rule to intermediate texcoords (i.e. the ones computed with light volume matrix but without texture matrix applied). Of course, it means that texture matrix has to be applied in fragment shader, while light volume matrix can be applied in vertex shader and get builtin prespective division.

One can of course do perspective division in fragment shader, but there is no reason to. In p.1, perspective division is only needed after applying light volume transformation. The texture matrix has dimensions 2x3, and only allows rotation, translation, and scaling. There is no perspective division involved when dealing with it. Technically, no light source should be allowed to light anything outside its light volume, because of the conflict with frontend culling/scissoring/triangle filtering. Ordinary lights are no exception. I don't really see why projected lights should be special here.

There is projection texture and falloff texture. For projection texture, mapper can/should set zeroClamp and the problem of going outside frustum by U or V won't happen. For falloff texture, mapper has no control over its clamping, it is just "clamp" right now. I guess the end values of falloff are not zero, because I see excessive lighting on test map due to falloff texture.

That fix broke scrolling light textures (5860). Aside from the matrix which defined light frustum, there is also texture matrix. The shader sees only the product of these matrices. My fix basically forces "clamp-to-zero" rule on both projection and falloff textures, while scrolling textures are specifically designed to exhibit "repeat" rule on projection texture. I see two ways to proceed: Pass texture matrix separately from the light projection matrix. Compute texcoord using light projection matrix in vertex shader, then force black color in fragment shader if texcoord is outside [0..1], finally multiply the texcoord by texture matrix in fragment shader. Rely on artist setting "zeroClamp" on projection texture, also enforce the same for falloff textures (right now they are always TR_CLAMP for some reason). Of course, in case of a scrolling texture, artist won't set zeroClamp. The only downside in p.1 is performance (although it is unlikely anyone would notice it). The downside in p.2 is that shader will still allow to highlight surfaces outside the light volume, despite the fact that various frontend techniques (culling and scissoring) will break it to various extent. P.S. Of course, the check that perspective divisor is positive (added by @duzenko) is a good one, it should retain no matter what.

I just tried to do a fresh installation of 2.09b (default version) from taaaki2 mirror, and it succeeded. It means that our mirrors are OK, the problem is either on user machine (broken hardware or malicious software) or in between his machine and TDM server (malicious network).

It won't work anyway because we don't have MacOS platform code. All the Linux-specific code won't compile/run, and there is no MacOS replacement.

It means the file has wrong contents after download. The previous user who had such error had failing RAM. I'd suggest checking RAM and HDD for any errors. Another possible thing is either a virus (something as bad as a worm) or antivirus (also, a bad one). @Wind_King, can you find files name tdm_installer_XXXXXXXXXX.log in your TDM installation directory ans share them here?

Is it a problem? I did not even notice it myself. Zip archive contains array of items. Every item has relative file path and contents, plus some other info. Every item is either a directory (filename ends with slash, contents are empty) or a file (actual contents are stored). The directories are optional: first version of zip format did not support them at all. The directory structure is not stored in zip, it is reconstructed by the program that you use to look into it. When I open this pk4, it looks normal, as usual.

Fixed in svn rev 9773 and 16423.

There is no HDR output in TDM, and it never was. The information in the wiki is very old and severely outdated. Please post a link so that we can mark it as such. It describes something called "HDR-lite", which existed in TDM many years ago. It was nothing like HDR by any sense, just some postprocessing image filter. Today we use HDR (16-bit color components) internally during rendering, but it is converted to 8-bit on output. I think supporting proper HDR output can happen, but only if one of programmers gets a HDR monitor to work on

Oh yes, that's the new subtitles from core assets in 2.10. I added a few subtitle lines for a particular AI for testing purposes. In general, you can avoid such spam by keeping Subtitles setting at Story level in the main menu.

Yes, indeed. You most definitely have sound samples for all the speech. If you assign subtitles to them, the engine will grab them while sound samples are playing. And you need to ensure that subtitles GUI overlay shows during these cutscenes, which I suppose just happens automatically.

As for size, I'd be glad to hear more opinions. Wide lines are used because this way it's possible to use large font, which can be nice for some people. Definitely won't change that for the reason @Dragofer mentioned.

Previously processing interactions on func_static_1032 took about 2500 us, now it takes about 60 us. I think the problem with this particular piece of geometry no longer exists. I used latest version with updated .cm file. I did not spot other performance differences. On my settings FPS was pretty much the same in two versions, probably because the particular part of frontend is not a bottleneck on my hardware. But for someone with weaker CPU (e.g. 2 cores) or disabled Frontend Acceleration FPS should definitely increase.

Subtitles in Saint Lucia added in beta210-03. Here is how they look:

The way volumetric lights are set up has been changed in beta210-03. Please read about all available spawnargs on the wiki page: https://wiki.thedarkmod.com/index.php?title=Light_Properties#Volumetric_light

beta210-03 is available. It is recommended to read full changelog is in the fourth post of this thread. Most importantly: Volumetric lights are set up differently now, maps need simple fixes. Frob-highlighting now works exactly as in 2.09.

Read this carefully: Quite likely, you have one of those situations where you think location separator applies to one visportal, but it is actually is applied to two, and you should fix it to be sure it works as intended. There were major changes in visportals system in TDM 2.08. If the portals were set before 2.08, then it is quite expected that some portals have dropped away. Otherwise, I can probably look into the problem...