Jump to content
The Dark Mod Forums

Leaderboard

Popular Content

Showing content with the highest reputation on 10/20/21 in all areas

  1. I can reinstall it this evening if nobody else chimes in. That said, the Github page: https://github.com/id-Software/DOOM-3-BFG under base / renderprogs appears to have all the shaders ? https://github.com/id-Software/DOOM-3-BFG/tree/master/base/renderprogs
    1 point
  2. @OrbWeaverLinear Z, huh? I was wrong then
    1 point
  3. I haven't seen the issue on any released FM, but I've only played a handful since the latest dev came out. Since I'm a bit hesitant to release a crap unoptimized WIP into the wild, and I definitely don't want to spoiler people on the cool puzzle I'm building, I'll PM you a download link. The maps folder contains the last non-buggy version and my latest test version with visportals turned to stone and all the scaled props deleted altogether. Watch what happens when you dmap and run the earlier map and then the later one in the same TDM session- suddenly it works!
    1 point
  4. I normally play with uncapped FPS off. Turning it on (166) makes no difference.
    1 point
  5. Ok, here is the analysis of the old R_SetLightProject code before @anonreclaimer 's commit broke it in rev 6684. Some notes: The inputs are the same as in the previous analysis: R, U, T are unit vectors from spawnargs, and W, H, D (aka width, height, and depth) are the lengths of spawnargs. It looks like "z" is the perspective divisor here, but it is applied only to "x" and "y". The falloff coordinate "w" should not undergo perspective division. You can see decomposition of matrix into three transforms, which produce homogeneous coordinates for "x" and "y" in range [0..1] both. Computation of the falloff coordinate "w" is totally independent of this transformation. Falloff parameter at a point is determined by its projection to "start"-"end" line segment: it is 0 at start, 1 at end, 0.5 in the middle, etc. In fact, falloff parameter changes linearly from 0 to 1 while going from S to E. Note that it does not depend on the frustum at all: you can e.g. have frustum direction and falloff direction different. Frustum half-angles are same as in BFG case: length(right) / length(target) and length(up) / length(target). If R/U/T triple is not orthogonal, then things go equally uncertain as in BFG case. Except that here T is made orthogonal to R/U plane, and becomes N. At the same time, size D is adjusted too: we take length of "target"'s projection along N instead of full length of "target". This perhaps gives some sense to the whole stuff when R and U are orthogonal but T is not. According to p.6, this code supports T not being orthogonal to R/U plane in some sense. In fact, only the component of "target" orthogonal to R/U plane matters, the component along R/U plane is dropped away. Note that you cannot create a non-orthogonal light frustum, so this "support" does not offer any additional flexibility. The case of non-orthogonal R and U still looks like unsupported/unintended. Here is how this light can be set up: Specify X/Y coordinates on frustum "screen" by choosing orthogonal "right" and "up" vectors. Specify direction of light frustum by setting "target" vector. Only the orientation (which side of the plane "target" looks into) matters. If you set non-orthogonal "target", then it is automatically replaced by its projection onto X/Y plane normal in the engine. Set lengths of "right" and "up" in such way that (target +/- up +/- right) vectors look through frustum corners. Here "target" is the orthogonal vector already "fixed" by the engine if you set it non-orthogonal. Choose "start" and "end" points completely independent of all the previous parameters. Falloff parameter ranges from 0.0 to 1.0 as you move point from "start" to "end". Gradient of "falloff" parameter goes along "end" - "start" everywhere. DeriveLightData_Spot_D3.pdf
    1 point
  6. You can try greebo or STiFu or nbohr1more greebo and StiFu have been with the mod pretty much from the start and they are German native speakers, but I do not know whether they have time for you. Nbohr1more (from the US) has been doing most of the PR work the past years so he might be an option as well. STifU is on vacation this week.
    1 point
  7. You can check if the map works properly on TDM 2.09. If it does, then bisect over dev builds of 2.10 and see which dev builds is the first non-working. After that we can looked at changelog and maybe we'll guess what is the problem. Although I think at least some understanding about how it happens would be welcome. By the way, when player1 is said to be outside world, where are you located? Are you somewhere in the void, or are you still standing at starting spawn location?
    1 point
  8. These are errors in compiling WIP volumetric light error. @duzenko might be interested in seeing them, but this shader is only used if you use "volumetric" material keyword, and it only affects graphics: shaders never affect gameplay. So, it is completely unrelated to your problem.
    1 point
  9. The backstory to my still-WIP warehouse FM contains a few loose connections already, so I've decided to flesh it out a little more and turn the story into its own little FM for the challenge. I've given myself a cap on the number of "rooms" to avoid feature creep, and I'm about 80% done with the blockout. Hopefully the deadline will help me push this one over the finish line, plus having a prequel will let me cut back on the intro and readables in the following FM.
    1 point
  10. Christmasy enough for the Christmas contest? The local Watch guard kicked his head off for being right on his patrol route, but it's the thought that counts right?
    1 point
  11. Not wishing to do anything is not exactly a great start for support request Sorry for being the Negative Ned
    0 points
×
×
  • Create New...