stgatilov

Where exactly? Could you please post getviewpos coordinates?

That can be considered an optimization: C/C++ compilers most likely do the same today, although the specification is defined in terms of having a separate preprocessing pass. The main consequence is that the preprocessor does not know anything about GUI language, and GUI language does not know anything about preprocessor, and the information just cannot get from GUI language to preprocessor. The formulation of a separate pass make it obvious, while the exact description of implementation does not.

It won't help, I'm afraid. You can try to find first version which does not work as intended, but if that's something before 2.09, that knowledge won't help. You can submit console log for a rare chance that it contains something suspicious. You can try changing antialiasing, anisotropic filtering, and maybe try "r_useNewBackend 0".

OBJ does not have anything like LOD info in the format. It only allows aplitting geometry into groups/objects of different names. Putting all the LOD settings into OBJ is barely possible. Maybe it is possible to use defaults in such case, but wouldn't it be better to implement some Blender export or DarkRadiant import for such case (i.e. that would create entityDef automatically) ?

Just reset your config (delete darkmod.cfg) if you can't find what's the problem. Of course, you'll have to set all settings except for keybindings from scratch after reset.

Fixed the number

beta211-04 is available.

Yeah, instancing takes less memory bandwidth than simply copying geometry withint the same model. You absolutely need good-made LODs in outdoor areas. On top of that, you probably want to have a few different tree models to create a forest. So it would be more like 10-15 variations, with 100-200 instances each.

beta211-03 is available. This is probably the first beta that Windows + AMD players can play normally, since the previous versions had massive performance regression from 2.10.

Better debug the test map with only func_static-s with "gui" spawnarg, find why the issue is happening, and fix the root cause

By default executables are copied to ../darkmod directory. That's the layout all developers have. You can disable COPY_EXE cmake option if you don't like it.

I use GCC 5.4.0, stock on Ubuntu 16.04. The reason for staying on old version is to generate binaries against old enough GLIBC, so that users can run them on their system (unless it is even older). Some other people (@nbohr1more, @MirceaKitsune) use whatever they have... This error is from doctest: /home/user/tdm210/ThirdParty/artefacts/doctest/include/doctest/doctest.h:3998:47: error: size of array ‘altStackMem’ is not an integral constant-expression 3998 | static char altStackMem[4 * SIGSTKSZ]; | ^ It was fixed in doctest 2.4.8, as described here: So it should happen on trunk (but happens on 2.10). Given that this is header-only library, you can download its header and put it into ThirdParty/artefacts/doctest manually. I wonder what's the problem with current trunk?

The captured file is useless unfortunately. Because RenderDoc replays these commands on my hardware... I don't even get the correct image.

@AluminumHaste, didn't you allow me connection with TeamViewer to resolve this problem previous time? Maybe we could repeat this? The idea is to run TDM under RenderDoc, capture one frame. Then take one block, verify that it is NaN, get its center, and trace back where this NaN started. Then review and tweak that shader until the problem is gone...

This is the new part in 2.11. This was always the case. The engine composes a virtual filesystem with a list of search paths. In fact, even if I wanted to load the file which is overridden, I simply could not do that: the two files have same path, and using it always yields the same file. Yes, it was always the case. And then FM takes precedence over core, and among them ordinary directories take precedence over pk4 (if I recall correctly). This was the case in 2.10. Right now you just get an error if there is such kind of conflict. Frankly speaking, why do you even want to silently have same decl in several files? How are you going to debug this? Just guessing that your decl does not work as intended because probably it is duplicated somewhere and running a search over all files in directories / pk4 files?

There is no such "regular" rule. Up to 2.11, there was no rule about duplicate decls at all. There is such common rule for the files. If you unpack your FM and keep filenames same, then unpacked files override files inside pk4 and you should get no duplication. But if change filenames, then the game sees same decl in two unrelated files, which is a duplicate. We only have rule for mission > core override, but decls inside pk4 and inside ordinary files are essentially the same thing. I can probably change it to warning if that would make life easier.

Models and textures are of course rendered from the same data. But draw calls are made individually for every instance --- we don't use instancing. What's the point of instancing? Ask yourself: how often you see many objects with exactly the same model in one view? Mappers try to make some variation, otherwise it looks weird. Also, the engine does animation on CPU, so animated models don't share the geometry being rendered.

I suppose it is. But I need something more specific, like exact message. Also, I don't understand how it can happen "on some occations". I thought this part of code is deterministic: if you get it, it won't go away until e.g. you change a file.

Regarding scissors: it will be fixed in 6099, but after 2.11. If you see some other problems (aside from cut headtops), you can leave a comment there. Regarding bindless textures, I hope they'll never be restored. Because in OpenGL they are completely unmanageable: you cannot debug it in any tool, and any error can crash the whole application (or driver). I've heard in Vulkan they did it in less barbaric way, so the their bindless textures are handled by various tools. Also you understand multidraw incorrectly. Rendering several copies of same geometry is called "instancing", and can only help when you know objects are the same... which is pretty rare I guess.

Yeah, I don't think it helps much either. Compiler can use more instructions, but it can rarely help... maybe BMI could make a difference. By the way, usually people write -march=native to compile for their CPU.

Yeah, but mainly because we have just sold the goat

Yeah, I guess you are the only one remaining. I have blocked CMake build on GCC without specifying CMAKE_BUILD_TYPE to avoid such confusion in future. Hmm... I guess you feel like in this joke:

Perhaps you should add -DCMAKE_BUILD_TYPE="Release", since it is not clear whether build would be optimized or not otherwise. Also, you can try Tracy profiler to record a performance profile. Set "com_enableTracing 1", then download Tracy viewer of appropriate version. More details on wiki page. With Tracy, you can see a lot of things immediately, e.g. whether it is GPU or CPU which is slow, which parts are slow, etc.

In svn rev 10212, I replaced errors/crashing with 30 retries (once per second), ending with disabling com_automation.

It is pretty strange that it crashes. But I can easily reproduce it on Windows. Just open two TDM instances and set "com_automation 1" in both. Obviously, it gets fatal error That's not right.