stgatilov

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...

@JackFarmer, I have just committed an optimization of collision model construction for patches (5859). I suggest you wait a few days, and dmap your next version with upcoming beta210-03. Note that you should delete .cm file before doing so (to be sure it is rebuilt).

It might be permission problem. If you ran tdm_installer under admin when installing game, then the game directory is now "owned" by admin, so you must also run the game under admin, otherwise it cannot modify files in its directory. To check if this is a problem, try to create some text file in TDM directory and save it. If you are prompted for elevated rights, then that's indeed the case. You can edit permissions of the directory to return it back to user.

If you really want to see what's the problem, then you should download Tracy viewer and run it. Then run TDM and get to the problematic location. When you are there, open game console and execute "com_enableTracing 1", then in Tracy click Connect button. Switch back to TDM and wait for a few seconds, then switch to Tracy and click Stop. Now you can inspect the timeline, and there is an option to save trace --- this way you can lend it to us for inspection.

That's discussion for a very uncertain time, I'd say. The current system is so vast, that it takes a lot of courage and time to start reworking it. I have the following ideas regarding localization: Allow string placeholders in addition to numbers (in fact, we already have some in 2.10, and nothing broke) Allow localization to replace by full-text match. That's crude, but mappers won't have to do anything to support such localization, and no changes are needed on DR side too. Throw away perl scripts, and reduce script usage to minimum (which is hopefully zero).