stgatilov

I know of the issue with rope physics. The problem is that presence of issues with uncapped FPS depends on FPS. And most testing efforts covers higher-than-60 FPS. It seems that with low FPS time delta is allowed to grow arbitrarily large, which is dangerous for physics. It is not clear yet what to do with it.

Ok, so here are the facts: 1) TDM game run on my machine produces correct lighting. 2) Your trace replayed on my machine produces correct lighting. And as far as I understood you: 3) TDM game on your machine produces wrong lighting. 4) Replaying my trace on your machine produces equally wrong lighting. Which means that only the sequence of OpenGL calls matters for this issue. Rename the cmd.trace which you downloaded from me into stgatilov.trace. Then run the following command: C:\apitrace-msvc\x64\bin\glretrace -D 593599 --dump-format json stgatilov.trace >stgatilov_call593599.json 2>stgatilov_call593599.errIt should replay my trace up to some specific point and then dump the whole OpenGL state into the json file. Upload the stgatilov_call593599.json file somewhere and post a link --- I will look into it trying to understand what goes wrong, maybe even compare it to the state produced on my machine. Also provide contents of stgatilov_call593599.err --- either upload it somewhere or post it right here inside spoiler tag. The call 593599 renders some part of floor, I guess. I'm mostly interested in contents of attached texture0, since it should contain normal map. Anyway, the json file will allow to see the whole GL state. P.S. Thinking about it, if the problem started happening after driver update and is perfectly reproducible with a trace, then someone from AMD could easily do bisect over their history (it seems to be one of the major use cases for apitrace) and check when it broke.

Ok, let's try some heavy weapons. If you have limited internet or internet with per-traffic cost, please ignore this post. 1) Download mission called "Closemouthed Shadows" in TDM --- this is sort of the smallest full FM I know. Make sure you have clean darkmod.cfg (except for resolution/fullscreen changes: set it to window of some size). Start the mission and check if the starting area is lit correctly. If it looks obviously wrong (I guess it should for you), then proceed to next steps. Otherwise stop here --- we need a better test case. 2) Download latest apitrace: binaries here Unpack it to some directory, e.g. C:\apitrace-msvc 3) Download trace file from my machine: here it is. Then run program: C:\apitrace-msvc\x64\bin\qapitrace.exe. There click File->Open, choose the downloaded cms.trace file. Then click Trace->Replay, leave defaults and click OK. A window looking like TDM will pop up shortly. It will quickly load mission and render something. Look how it renders the starting area: is lighting correct? P.S. This is the sequence of OpenGL calls recorded by me on my machine with beta207-08, and replayed on your machine. Although to be honest, I'm not even sure this thing will work: for me it looks like magic 4) Now the hardest point. Probably stop after step 3 and report your results for now... Make sure that "Closemouthed Shadows" is the installed FM in TDM. Execute the following command line in the TDM installation directory: C:\apitrace-msvc\x64\bin\apitrace.exe trace --api=gl --output=cms.trace TheDarkModx64.exe +map closemouthed_shadowsThis command line should start TDM and start the map immediately. After map gets loaded, click attack immediately and step back as in the replay video you saw in step 3. After about 5-10 seconds press Alt+F4 to kill TDM game. Find file cms.trace in the TDM directory, it should have size like 200-300 MB. Upload it somewhere so that we can download it (e.g. google drive). P.S. It would be great if someone from TDM team could do steps 1-3 first, so that we know at least that this workflow makes sense.

No errors, no ideas. I compared HMart's condump to mine, the only difference I noticed is: Generated framebuffer DEPTH_STENCIL attachment: 1920x1080 Generated framebuffer COLOR attachment: 1920x1080 Generated render buffers for COLOR & DEPTH/STENCIL: 1920x1080x0 Generated framebuffer DEPTH_STENCIL attachment: 1920x1080 This is excerpt from my dump (near the end), and HMart's log misses the last line. I wonder why I have this generated twice, but HMart has it only once. Aside from that... did someone of you perform "clean install" or driver? (I'm not sure how it is called in AMD case) Is there any way to find anything like a cache and clean it? Also we can try to find some other player with AMD cards of approximately the same year, ask him to update GPU driver and check if he has the problem. If he has, then it would make it obvious that modern AMD driver has some relevancy here (and the victim will probably hate us afterwards ).

I don't believe there is any driver bug. The S3TC support is known as "ubiquitous extension", meaning that everyone supports it for a long time without caveats. I'm pretty sure there is some issue in the game which sometimes shows up. Please try to set r_ignoreGLErrors 0 immediately after starting TDM and load mission again. Or even better, start TDM with command line arguments: TheDarkModx64.exe +seta r_ignoreglerrors 0 After mission is loaded, save a condump and attach here. Hopefully, it will show some OpenGL errors, although I'm not sure they will be descriptive.

Yes, but the third way completely disables bumpmapping in the shader, you won't be able to enable it back even if you restore r_skipbump 0. So this is not a complete solution yet. Anyway, this gives some idea of what is going on. It seems that fetching bumpmap texture yields trash. Given that the objects look completely flat, I assume that it returns constant value (same for all fragments). And given that it looks wrong, I suspect that it may be black color (which corresponds to weird (-1, -1, -1) normal). And if this is true, then it means that bumpmap texture is not loaded properly into the GL pipeline. Or the textures are loaded from file wrongly, which is less likely. Does release build/config show OpenGL errors in game console? If not, we should enable it and see if there are errors.

Better backup the whole tdm_base01.pk4 before changing it, and restore it after changes! Please try to go to glprogs/intersection.fs inside tdm_base01.pk4. Ensure that you have Stencil shadows enabled in TDM (r_shadows 1). Now find the lines in the file: vec3 RawN = u_RGTC == 1. ? vec3(bumpTexel.x, bumpTexel.y, sqrt(max(1.-bumpTexel.x*bumpTexel.x-bumpTexel.y*bumpTexel.y, 0))) : normalize( bumpTexel.wyz );Replace these lines with one line of the following: vec3 RawN = normalize( bumpTexel.wyz );vec3 RawN = normalize( bumpTexel.xyz );vec3 RawN = vec3(0, 0, 1);After trying each of these three cases, perform reloadGLSLPrograms in the game. Don't forget to pack the pk4 file back beforehand (in fact, it is easier to unpack it if you know how). Report back how these three cases influence lighting. Which make lighting good? Which retain it in the same buggy state?

You can try to disable it and see if the issue disappears.

I guess the latter. That is a major sign saying that the beta phase should end soon.

Yes, Bluehawk's issue looks like the same as I had. HMart's issue looks different. Unfortunately, I cannot tell exactly what I did to make it work. I updated drivers from NVIDIA site, rebooted machine a few times, probably removed darkmod.cfg a few times. Also you can try to rerun updater to ensure that you have correct packages. Maybe even remove tdm_base01.pk4 before that (it contains shaders). At some moment it has simply disappeared, and I had no idea what cause it and what fixed it. You can also try to edit glprogs/interaction.fs inside tdm_base01.pk4 by changing something, do reloadGLSLPrograms, then return back and do it again. The picture 1) has no bumpmapping, and 2) has wrong normals. Probably it means that the contents of normal maps become wrong (e.g. filled with some constant color). I thought maybe it is related to normal maps compression, but it seems to be disabled by default, and you said you deleted config file. UPDATE: Created issue 5031 to track this problem (long time after it has been fixed).

I guess no. It seems that Raspberry Pi today has desktop OpenGL 2.1 (which seems to be enough for TDM). However, it uses ARM cpu, which is going to cause many issues during build (most likely solvable, but would take considerable time). Currently TDM officially supports x86 CPUs (both 32-bit and 64-bit) with Windows or Linux OS. Some code for PowerPC support is present also because original Doom 3 used to run on old Macs, but I'm not sure if it is working today.

New beta build (codename: beta207-08) is available. Changelog is here, as usual. P.S. Please play some time with Stencil shadows. I have a feeling they are overlooked

STiFU has already done it, it is included in 2.07. I guess it is some sort of standard in Windows world, although I won't be surprised if many programs omit it.

Please report if you have "Uncapped FPS" on. It has huge effect on physics, and combined with low FPS it can wreak havok.

If you ask me, I would happily delete all those things called "rim light" and "fresnel" from the shader. At least for 99% of objects. All those weird components raised to insane power... they are doomed to have unintentional effects. Speaking of the crate tin WS4, its lighting is weird even with simple shader. But simple shader doesn't have all those risky components, so it does not look so obviously wrong. Try to move candle yourself near the crate with simple interaction. It is not correct. UPDATE: added an image into 4955. The crates have smoothed vertex normals, which generates absolutely crazy tangent space, so any hope of proper lighting disappears.

Yes. I added some missing clamps, and now it should work exactly as the old shader did in 2.05. And in 2.05, the crate looks exactly the same. I think in the end it is the crate which should be fixed.

I found the commit which caused the problem --- see issue 4979.

I'm already in process of "bisecting". Unfortunately, the issue is older than automation, which makes it slower. Also created issue 4979.

Stencil. One way to reproduce is: boot up e.g. Chalice of Kings and teleport e.g. to (3877 3265 160). There is guard standing there. Obtain a lantern somehow (e.g. spawn atdm:playertools_lantern and pick it up), enable it and fly around him.

A funny thought came to my mind. Can't stand but share it. Git came out 3.5 years before bitcoin. Notice that: 0) Git computes SHA of commit by hashing the whole contents of the commit including SHAs of parents. 1) Harden SHA computation with nonce concept, i.e. enforce that SHA ends with K zero bits (by varying a useless "nonce" parameter inside commit). As a result, you get a blockchain. 2) Store only one file with the list of money transactions in the repo. 3) Make it mandatory for users to sign their payments with their SSH private key. You got a cryptocurrency. Should we call it GITCOIN? A minor note: all requirements should be checked in the main commit validation code, so that every client checks every commit the same way and ignores invalid ones. This includes: a. The only file is a list of transactions, and every commit only appends to this file. b. Every ordinary transaction must be correctly signed by payer. c. Allow one special transaction without payer per commit, with value computed using hard-coded formula --- this adds emission. d. SHA format requirement from nonce. The number K is computed from current date: increment it every X days and you get finite supply. If some people try to establish different rules, they will get incompatible history. It is called a hard fork. The impact of this fork depends on how much people start using it. It looks like the shortest way to explain how bitcoin works internally to a seasoned programmer

New update is up: beta207-07 Please update. This is considered a "release candidate". Meaning that most likely it will become the final 2.07 release.

Added beta207-06, and fixed beta207-05 on tdmcdn.azureedge.net (way 2b).

New release codenamed beta207-06 is out. Update as usual for beta. Changelog added at the very beginning of this thread.

I updated the wiki page with information about Version 2 of EFX file. I think whether I should delete the section "Legacy info (Version 1)" altogether or not...

Please also provide your config file (darkmod.cfg). Also could you explain what exactly you did before crash? Was it immediately after a fresh start of TDM? UPDATE: I tried stupidly to fresh-start Arena mission 100 times, got no crash.