stgatilov

I ran it locally under procmon, and yes, it tries to load this file. Don't know exactly why, but I suppose that's something from DirectInput (or OpenAL-soft maybe).

Yeah, waitFrame is a very uncertain duration with uncapped FPS.

Look at this: https://bugs.thedarkmod.com/view.php?id=4854 Non-axis-aligned walls result in wrong collision model at 40K. I spent considerable time trying to understand what causes this, but did not succeed. And despite many fixes/improvements in dmap and such, this bug still works perfectly the same.

The main problem with LWO is that engine always "fixes" them, which often breaks them And engine cannot be changed due to backwards compatibility. On the other hand, now we have OBJ support, which does not mess with geometry. I already suggested to provide a way to load single group/object from OBJ by its name, by writing model name like "mymodelfile.obj$group=lod0". This way we can store all LODs in one OBJ file. Maybe we can extend this group selection to other formats, although that would be harder. Speaking of default distance. The formula should be something like distance ~= A * sqrt(TriangleCount) with some constant A. I suppose constant A can be deduced by setting approximate average size of a triangle on screen with some default resolution (e.g. FullHD).

I think the real efficient limit is about 10K. Beyond that you risk getting physics/collision problems that will not be fixed, unfortunately. On the other hand, if you want to set some kind of background stuff which does not use physics and is not involved in gameplay, you can try doing that. For example, Swing mission creates swinging background, which is pretty large: larger than 10K. And it works well. Speaking of skybox, I have no idea why you want to put it that far. Just find some unoccupied space in the void, create heavily minified version of skybox there, then use the engine skybox feature.

Regarding switching fog in northdale1 at "400 -1220 286". This issue happens in 2.10 too. It seems to be caused by a conflict between two fog lights: "light_116" script-powered fog system of "atdm_location_settings_1" When I "remove" the individual light, or comment out script-based fog, then fog looks the same regardless of camera direction. Doom 3 fog is rather hacky by itself, I doubt two overlapping fogs are supported @Goldwell

I tried Output on SVN and latest beta, on Easy and Hard difficulties, the candle always looks properly extinguished. This is the "StaffQuarterCandle" entity at 1165 147.5 -178.25. The only thing that I noticed is that if I immediately teleport to it after the game starts, I see smoke going from it for some time. I guess because it gets extinguished on game start. I doubt player can see it. If you have this issue: specify which beta version it is (remove mods), delete FM directory and download fresh FM, try to reproduce it from clean start, post your screenshot and darkmod.cfg.

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.