stgatilov

Ooops Most likely I'll look into it somewhere during beta-testing. In the worst case I can just allow larger force on rats, so that player could carry rats, albeit with swinging issues... or revert to the old code for 2.10. But please remind me about it so that I don't forget!

Look here: https://wiki.thedarkmod.com/index.php?title=Setting_Reverb_Data_of_Rooms_(EAX) late_reverb_delay must be in range [0, 0.1]. And I think other options are pretty high too. What if you set these settings to zero? Do you hear the difference?

I'd be glad to, but my minimalistic attempts to fix this have failed so far. I guess I'll have to refactor the whole place a bit. Also, I'm afraid hurrying up is a dangerous approach... In the worst case it's better to postpone this problem until 2.11. That would mean I'll revert your fix for (far+near -> far), because it's better to have two different behaviors to deal with than to have three of them

One thing I don't understand is that Doom 3 projected lights don't have "light radius" spawnarg. So, target/right/up define an infinite frustum which should be capped from the front and back by start/end parameters. However, if end-start vector is orthogonal to some light ray, then the start/end clipping plane from Doom 3 do not cap the frustum. In this case, the light volume becomes infinite without any diagnostic: the set of light planes does not bound a volume, and the light polytope has planar faces of size 128*1024 and is not closed.

If you want your volumetric light to behave the same way as projected lights, then you cannot use the matrix from BFG anyway.

There is no frustum in Doom 3, there is a set of planes. And as a set of planes, it has no issues. I'm pretty sure the code to compute vertices can be modified to fix the problem. But it is not clear how important they are.

Maybe try to switch between fullscreen / windowed? Do you have several monitors or something extraordinary about desktop/monitor/mouse?

Yes, indeed. In the worst case you can find always source code for a preset, copy all its attributes to your EFX file, then edit them as you see fit. But according to wiki article, you can override selected properties by writing them after preset line.

I think if we want to restore Doom 3 behavior, we should revert that change and remove BFG-style light matrices. That would make life much easier in the future. Before the change, there was one matrix stored in light. After the change, there are three matrices, two of which are inverse to each other. Now if I try to reproduce old behavior but retain the new BFG matrices, then the two matrices would become different: one would store actual light projection data, the other one will represent some bounding frustum. I imagine that would be endless source of confusion, and will cause similar problems in the future in case someone decides to touch this code. If we remove both BFG-style projection matrices, then everything will be simple again.

Not really. In fact, my check in case 3 is wrong: the falloff is different when S->E is not collinear to normal vector (N = R x U), not the target (T) one. Basically, almost all cases from p.2 are also affected, i.e. I cannot reproduce their falloff behavior with BFG code. That includes maps: Basically, tons of FMs are affected. And there is no way to reproduce their falloff behavior from TDM 2.04 with current matrix-based code. Some of them were released after 2.05, so they should work as intended now (and will stop working so). spotlights_SE_N_noncollinear.txt

I fixed the issue in svn rev 9643. For the previous dev. build, I fixed some weird behavior which looked like a bug, but it turned out that some code was working only thanks to that weird behavior, and hence it broke. Here is the difference between working and broken maps: If .map file has "name" spawnarg set on the worldspawn, then the map loading was broken. If .map file does not have "name" spawnarg on worldspawn, then it map loaded fine. Of course, some existing FMs (e.g. Window of Opportunity) have "name" spawnarg, so that was a serious issue. The next dev build should work fine in all cases.

If you read the whole topic, you'll know that 2.08 does not work. 2.07 is the latest version which works.

Let me be frank: I have absolutely no idea what's wrong and where to search. We can of course try to investigate it, but most likely it will take a lot of time and effort, without any guarantee of success (we can find nothing, or find something that we won't be able to change anyway). Indeed, it would be great to make TDM work on GPUs of your class because they formally support minimum required GL version, but I'm not sure you want to go this route without much hope for success.

It applies force equal to some hard-coded ratio (less than 1) multiplied by weight of the body. You will have the same success as with a rat

It is used for all bodies. Should it be relaxed for rats?...

It seems that TDM does not render on Terascale1 GPUs... I wonder if this is the problem with menu only or with all rendering? For instance, if you unpack the attached zip into TDM installation directory, and then start the game with command line parameters: TheDarkModx64.exe +map test/5598_crazyhedge.map UPDATE: After some time you need to click (attack) to start gameplay... Will it show anything when game starts? (if you are not sure you did everything right, you can look at game console: it will print a lot of stuff when you start a map, plus sounds will change too) maps.zip

Perhaps it would be a good idea to check the "Beta Testing 2.08" thread and try to change cvars listed there. For instance: r_uniformTransforms 0 r_fboColorBits 32 r_usePersistentMapping 0 r_useMultiDraw 0 and r_useBaseVertex 0 (I guess they don't exist in 2.09 anymore)

It says "This file is not public." to me.

At some moment in the future we will release 2.09b fixing that. As of now, either use the latest dev build, or edit darkmod.cfg: seta r_glCoreProfile "0"

Most likely we will release 2.09b hotfix fixing that in a few weeks.

I searched for spotlights in released FMs: Non-orthogonal T/R/U is used frequently. T not orthogonal to RxU plane is used frequently. S->E direction not collinear to T is used rarely. I have attached log files showing all problematic entities in each category, with sine/cosine of angle printed for them. Low numbers means that directions are almost collinear/orthogonal. So, we can supposedly leave arbitrary start/end case broken. In fact, I'd say it is better to forcibly project "start"/"end" onto "target" direction. The most important broken cases would be light_attic_yellow_window in bcd and light_7 in windowopportunity. As for near/far planes, @duzenko has already committed the change to return to old behavior: just use "end" - "start" instead of "end", which means that far clipping plane is now at "end" and falloff parameter = 1.0 at "end" too. But as for non-orthogonal T/R/U, I guess we'd better reproduce the old behavior. spotlights_TRU_nonortho.txt spotlights_RUplane_T_nonortho.txt spotlights_SE_T_noncollinear.txt

I reproduced the error on current SVN. The warnings are generated because world bounds are "(0,0,0) - (0,0,0)". Since most entities are far from origin, this warning is printed for them. It also explains the weird "memory effect" that you are seeing: proper bounding box was loaded during previous map start, but bounding box is not updated updated during current map start, so the bounding box from the previous start retains. It might be totally incorrect if two maps are unrelated, but in your case it stops the warning spam. I did not get to the root cause yet, but will do in the future. Most likely something about loading collision models got broken. I refactored/optimized something related to collision models loading in the latest dev build, and probably did not test it well enough to notice that I broke stuff real hard. Meanwhile, use previous dev build. Also, if someone else sees the same problem on the latest dev build, please report it here. I'm not yet sure if the problem happens always, or is specific to this map...

Your Windows says "tdm_installer is not responding", but it still refreshes itself occasionally --- that's OK. The reason is that tdm_installer is completely single-threaded, and it can only handle user input when it is not doing something useful. That's rather poor way of writing GUI applications, but I did it in order to avoid any kind of errors that multithreading can easily bring. Regarding errors: I can't say anything without knowing the exact error. In fact, the best way to diagnose installer errors is to attach tdm_installer_XXXXXXXX.log file. A new such file is created every time you start the installer. If you are not sure which of these files captures the problem, just zip and attach them all.

Regarding 2.09 vs 2.09a / hotfix: Did you install TDM using tdm_installer.exe ? You can see whether you have 2.09a or 2.09 by looking at .zipsync/lastinstall.ini: [Version] version=release209a Or you can find line seta logFile "0" in darkmod.cfg and change it to seta logFile "1", then find qconsole.log and attach it here. It should contain engine revision number, which can be used to understand which version it is. Anyway, your problem will most likely happen both in 2.09 and 2.09a. Regarding the black screen problem. Most likely it is the same issue @freyk linked above. Especially since you confirm that test15973-8787 works properly. The current workaround for this problem is to set following in darkmod.cfg: seta r_glCoreProfile "0" After that 2.09a should work fine. Also, this problem is fixed on the latest dev build. But dev build are not recommended for normal playing: better use release2.09a with core profile fix. Also, I think we will release another hotfix for 2.09 (that would be 2.09b) somewhere in November. Specifically to fix this particular problem, and maybe something else. Make sure to install this second hotfix when it is released.

No. We should differentiate between convention (is falloff in Z or W? should it be scaled by some number?) and behavior (shape of frustum, falloff value). Yes, the current code converts the matrix from BFG convention to D3 convention, but it does not & cannot convert behavior. And behaviors are different between D3 and BFG. If start/end vectors are not collinear with target vector, then you cannot convert D3 matrix in such a way that idRenderMatrix::ProjectedBounds/baseLightProject would work properly with the result. In BFG, light volume is always a frustum, but in D3 its near/far planes can be arbitrary. Maybe something can be hacked by making target vector non-orthogonal to R/U plane, but I'd better avoid that.