stgatilov

Some time ago @duzenko implemented automatic gamma adjustment depending on what player sees. The idea was met without enthusiasm. Maybe it can be applied in this case? If a considerable part of the screen is overly bright, then automatically lower the gamma. But never raise it in darkness... since most people agreed it somewhat defeats the whole light/darkness feel.

I remember there were two modes: update on map save, and update on any change. Perhaps you were using the former approach... Tooltips should know better

There is no technical possibility to apply separate gamma, because gamma correction is done on the whole contents of the screen, including all GUI. Initially @cabalistic tried to do it before GUI, but we soon discovered that underwater overlays are also GUI, and probably something else too, so we decide to simply return the old behavior. That said, it is probably possible to apply second gamma correction on the GUI itself, but I imagine that would be quite a hack.

Are you asking as a mapper or as a player? I think the current intent is: mappers draw GUI texture as they want players to see it. Players see it more or less is it was intended.

Yes, the shader does not compile: uniform usampler2D u_sourceTexture; vec4 sample(ivec2 pixelCoords) { // fetch from base LOD level return texelFetch(u_sourceTexture, clampPixelCoords(pixelCoords), 0); } Since texture is usampler2D, texelFetch returns uvec4, i.e. vector unsigned, while the function should return vec4, i.e. vector of floats. However, according to official docs , it should work: So it looks like an issue in the driver. Try to put the attached file into glprogs directory in TDM root. It will override the file you have in pk4 archive. I added an explicit cast to vec4 there. tiled_custom_mipmap.frag.glsl

You don't need to make it adjustable. Since TDM rendering is gamma-incorrect, the same highlight will automatically be more visible when added to dark color. Adding it to bright color will be hardly visible.

Perhaps add a bit of highlight to raised blackjack? That would fix the problem with dark areas. To be honest, I can't understand how raising the blackjack higher is supposed to help in pitch black area where you don't see blackjack.

Post darkmod.cfg and condump then.

I think not, because it is not a feature, it is optimization. Neither players nor mappers really have to know about its existence. The reason for this thread was to check what beta-testing players would say about performance: it is better/worse and how much. This is for stencil shadows only, not applicable to shadow maps. Stencil shadows do have larger penumbra at larger distance from light: it is distance to obstacle which is ignored by stencil shadows but used by shadow maps. This technical limitation is hard to workaround without shadow maps.

There is nothing like "new frob-highlight", nothing has changed in the way highlight works. What's new is: Rule for generating frobstages implicitly. Some new "frob macros" that you can use for the rare cases where default looks too bad. Under the hood, there is nothing new. Both implicit stages and the macros are 100% equivalent to frobstages which are all over the core materials (and missions, I suppose) right now. The existing materials should look the same as they did. Although there is some risk that added implicit frobstages could break something.

I wonder if anyone else feels the hint animation is too strong? Wouldn't it be enough for a hand to travel 1/3 of the distance? It is especially bad when status changed quickly, so the thief moves his arm up and down as if he is itching to hit and can barely hold his hand.

New build dev16629-10139 is available.

The latest dev build (dev16629-10139) contains some changes regarding frob highlight. The full explanation is given in 5427. Most importantly, the material stages are now generated by default if they are missing. The core materials will be cleaned accordingly in near future. Also we added new syntax for customizing frob-highlight in simple cases. First of all, you can set frob-highlight with custom texture (e.g. it can be specular map) and arbitrary coefficients: frobstage_texture textures/darkmod/sfx/whiteglass2 0.25 0.5 Since diffuse texture is used in most materials, here is a shortcut for it: frobstage_diffuse 0.1 0.35 The first number is the multiplier applied to texture, and the second number is the amount of white color added. You can also make non-white multiplier or addition by putting three numbers in parentheses, e.g.: frobstage_diffuse (0.15 0.35 0.15) 0.4 Of course, the most recommended approach is to not write any frob text, in which case frobstages are added implicitly as "frobstage_diffuse 0.15 0.4". The implicit frobstages are added only if there are no frobstages specified explicitly. If you want to suppress implicit generation of frobstages (not recommended), you can write: frobstage_none Finally, if you want to make something special and customizations listed above are not enough, then you can just write frobstages the old way via parm11 parameter. The old frob-highlight stages should continue to work properly. If you write frobstages manually, please follow the rules (or you'll get warnings): Start every frobstage exactly with if (parm11 > 0) condition. Do not mention parm11 outside frobstages. P.S. Here is previous discussion of frob highlight, in case anyone is interested:

The latest dev build (dev16629-10139) supports Wavefront OBJ format for static models. Some details: Model must consist only of triangles. Quads/polys will produce warnings and won't work properly. NURBS/lines/etc are ignored. Normals and texcoords are mandatory for all triangles, otherwise model loading will fail. Widely used extension for RGB vertex colors is supported (standard OBJ does not support vertex colors). TDM materials are referenced by "usemtl textures/test_obj/rock". Standard MTL files are not supported yet. Unlike LWO and ASE imports, which try to automatically merge close vertices, no postprocessing is done for a model in OBJ format. As far as I understand, it means less suffering with smoothing groups for instance. Also it means that loading OBJ model is very fast, even for a large model. The only downside thus far is that zipped LWO file can be smaller than zipped OBJ, but I don't have exact numbers yet (I'd be happy if someone can help me with it). Speaking of OBJ format, there are several pending questions: Should we support MTL format (common subset) in TDM engine? Or as import plugin in DarkRadiant? Should we support referencing part of OBJ file as model in TDM map? Is it common to export several LODs into one OBJ?

Yes, the debriefing thing was changed during The Great Main Menu GUI Refactoring We updated the mission in FM database, but you are most likely looking at your own local version which is not compatible with the new engine. Download mission from in-game and take gui directory from there (perhaps compare with you local state using WinMerge).

dev16625-10132 is available.

Yes indeed. I think the discussion is here.

I hope @Obsttorte would correct me.| But I think these changes are already in the latest dev build.

Yes, indeed. @Obsttorte changed the way knockouts work.

Anyone else with the same problem, I wonder? Which exact version of TDM do you use? 2.10 release or some dev build? If dev build then which one and when did the problem start? Could you also post condump? It sounds as if ambient shader does not compile with SSAO, in which case you console should contain compile errors.

Well, the engine is not very accurate regarding first frames of anything, given that it has SMP and other things. I'd suggest trying to disable com_smp, maybe the issue will go away. When SMP is on, we render previous frame while we model gameplay for the next one. It might be a texture rendered specifically for X-ray, or some frontend data which is gathered for X-ray, etc. In order to find the issue, I'd recommend using apitrace to capture OpenGL replay (on a smaller map). It is not nice to use, but unlike RenderDoc, it captures every frame, so you can later find the glitchy one and see what's wrong in OpenGL calls. After you understand what causes this issue, a proper fix would probably be adding some kind of delay to X-ray visualization, or some kind of clear when X-ray is disabled/enabled.

Yes, I guess the manual download does not report that downloaded files are different from the ones website distributes. You can try to copy the TDM directory and run tdm_installer in it. It will check you local copy and only download/repack what's different. If it finishes successfully, then you can be sure you have the correct TDM 2.10 there (at least at that point).

The error says that after it has downloaded the file, its contents are different from expected. I have just tested clean installation of 2.10 with this mirror chosen (taaaki2). I cannot reproduce the problem. It means that the problem is most likely on your side. It can be: some rights/access problems in filesystem (try to create a different directory, make sure you can write to it yourself) virus or antivirus breaking data (disable antivirus, or run independent virus scans) hardware problems in disk or memory (run some good hard drive and RAM tests --- we already had one user who detected RAM issue after tdm_installer errors) software problem, like broken OS files, drivers, filesystem, etc (run sfc scan, chkdsk, etc.) your network broken either by bad adapter, cable, or by your internet provider

Scripting changes are only applied if you reload game, I can hardly call it "in real time" Anyway, I recommend: Get source code from SVN trunk. Get TDM installation (assets) of the latest dev build with tdm_installer. Read COMPILING.txt, align two directories as described there, build game. When you build engine from source code, it would copy/overwrite TheDarkModx64.exe and glprogs directory to ../darkmod. Yes, you can run and debug the game straight from Visual Studio, the solution is configured accordingly. If for some reason you want to keep clean 2.10 installation or dev build, just copy the whole TDM installation directory: you'll have less confusion this way. It is possible to have single installation but juggle around with executable and glprogs, but I wouldn't recommend that. Just like Doom 3 engine, TDM considers everything in .pk4 archives (they are actually ZIP archives) as a virtual filesystem. So if you take some pk4 file in TDM installation directory and unpack it to the same directory, the game won't notice it and wll work exactly as before. If you want e.g. to edit game scripts, find the pk4 archive which contains them, then unpack its contents and delete it. Then you can easily edit the scripts.

dev16617-10107 is available! I fear this might become the most breaking dev build of 2.11...