stgatilov

The built binary seems to work as expected on Elbrus machine (with RX250 graphics). The performance is pretty bad: on default settings it gives about 30 FPS on the start of The New Job. We will look further what is the culprit, although I suspect it is the CPU/memory. If you ask me, the platform runs pretty well overall, but is not a competitor to commodity x86 in terms of performance It's quite enough for office work, but games is another thing.

Could you please run the game under GDB and generate core dump? According to this, you can do: gdb ./thedarkmod.x64 run generate-core-dump Then find the core dump file, upload it somewhere and share here.

The material path can be replaced automatically. We can talk in more detail about it. As for the pivot point, I'm not sure what you mean. The coordinates of the model in world spaces are usually defined by the entity origin, not the model. If you are talking about choosing a point in model coordinates and saying "this point must match entity origin", then it all boils down to transformation. It is also doable. All of these are small inconveniences which are fixable with simple formats like ase/lwo/obj. However, FBX adds lights, cameras, animations, video clips, maybe particles, etc, all the trash which cannot be loaded. On top of that it is proprietary, binary, etc. Maintaining a plugin is the right way to go. That's what ID did. If you want to import models in FBX, then it is necessary to create an maintain a Blender plugin or an importer. The latter is quite unlikely though.

Then it's necessary to choose better tools or improve tools. But not load FBX directly by the game engine. I'm not against adding some other binary model format, as long as it is something simple. Here is one analogy: it would be great for the engine to load PNG files, but not PSD files.

I have same problem with these formats as with FFmpeg. Too much use cases, too much bloat. Unfortunately, we are hooked on the FFmpeg monster and cannot get out. But maybe not introduce more monsters? Basically, this:

I think it is related to 3989. I would appreciate if you write exact steps to reproduce the problem. I mean a list of the actions that player must do, including coordinates of all locations.

Meanwhile, I have managed to build TDM for Linux/Elbrus platform. We did not try to run it yet, but that is planned for the near future. I'm attaching a full patch against current SVN. I will not commit changes to ThirdParty/artefacts/ffmpeg/* and ThirdParty/artefacts/ogg/*, but will commit changes in ThirdParty/artefacts/devil/include/IL/il.h. Also, keep in mind that ThirdParty/custom/openal/conanfile.py.original is a new file --- it has no function but to mark TDM-specific changes to original recipe. Note that I did not do anything specific to Elbrus, only added missing checks for x86 architecture, and removed one weird check for LCC compiler. Fixed some generic bugs (i.e. wrong filename case on Linux --- was already reported by someone). Also, I extended third-party build system, now it is possible (although not very straightforward) to use it and build TDM for any architecture. I hope that guy with 64-bit PowerPC will also be pleased @duzenko, @cabalistic, I wonder what do you think about it. Can I merge it to trunk? Should I merge it to release branch? elbrus.patch

The number of mirrors is not too high today, and new mirror would definitely be welcome. However, we have been split on the question of whether we could use a server as official mirror when its owner has zero posts on these forums. The TDM code does not properly verify downloads, so we must be sure that mirrors owners can be trusted. Sorry.

Ping @Spooks...

Yeah, also keep in mind that the ugliness of SSAO is not noticeable on still screenshots. It exhibits light leaking behind edges of big occluders, which catch attention as unnatural when you move around.

Please download this binary and test it. The command is called overrideSurfaceMaterial, and it changes the material of the surface directly in the model. So all entities with same model are affected. Moreover, the change is persistent: I guess something like reloadModels all is needed to reset materials back to normal. TDM restart of course works too: the command never changes anything on HDD

I'm trying to popularize the new wiki article about reporting problems. It has a section about console dumps. Please read it carefully, and you will learn a way to capture a complete console dump up to the very moment of the crash. According to condump, you use TDM 2.07. Meanwhile, 2.08 beta has a fix against rare but well-known crash in AAS tool. It would be great it you try to dmap and play your map with latest 2.08 beta. If the problem happens in latest 2.08 beta too, it please provide your FM for inspection. Even if I won't fix it, I hope I would be able to narrow down the search for the culprit.

I think it is impossible to export particle effects from Maya, because Maya has its own particle systems, and Doom 3 engine has its own. As for MASH, it seems to be similar to the SEED system of TDM. Anyway, I think you can take the final geometry and export it as single mesh.

Greebo compiled maya plugin for up to 2012 version of Maya. You can download binaries here. I thought about refreshing this plugin, but it seemed to me that artists have abandoned Maya in favor of Blender.

I meant "nobody had time to clean in in TDM".

And by the way, do you try to compile it for x86 architecture or for Elbrus architecture? The Doom 3 code was pretty much tied to the specifics or x86 architecture, and I guess nobody had time to clean this up.

Which GPU exactly it has? Which version of OpenGL it supports? Do I understand it right that you have physical access to the machine, and in theory you can run the game (if everything is OK) ? It is not the best time to spend time on this now due to ongoing beta for the new release. But maybe I could try to fix build myself, if it won't take too much time. Although I don't think any changes will get into trunk before 2.08 is out.

Hello! I never imagined I will meet anything Elbrus-related in person I must admit I have more questions than I should Regarding the changes. I like them being so compact, but I think I have problems with both of them. The check for C++ standard is both unnecessary and incorrect. The support for C++14 in Visual C++ compiler is not tied to -std=c++14 keyword (which is not supported, I guess). I think CMake added special keywords for C++ standard exactly for this reason: different compiler implement this setting differently. And according to documentation, CXX_STANDARD_REQUIRED should already produce an error if C++14 is not supported. So I'd better not add an explicit check and more code. By the way, does LCC support C++? And C++14 in particular? Did you manage to build the engine in the end? The situation with il.h is more complicated. This header is merely a build artifact produced by conan. So if this change is applied as is, it will persist until someone decides to rebuild DevIL and commits new artefacts. Which probably won't happen soon though. Moreover, fixing this in DevIL repository also won't help, because DevIL has recently migrated from C to C++, which I personally won't like, so we stay on older version. I had an idea of wiping DevIL out of TDM, but that won't be easy.

There was an idea of creating a new GUI screen which would show in-game screenshot with sliders including gamma, brightness, and other postprocessing settings. See 5163

Perhaps it is time to fix it? I have no idea what to do. Except that delete the specularmap line. It is already fixed. Zero timestamp means that all files inside PK4 were last modified at the beginning of the epoch. Even if you change a file inside and repack it, the game will still think it was modified at the beginning of the epoch and won't notice changes.

With your config file, I cannot reproduce the problem. Are you using 4K monitor, several monitors, and/or GUI scaling in OS? It looks the same for me on GeForce too. Although I have both GPUs at once, so I'm not entirely sure. The reason I did not notice that is that my taskbar is usually auto-hiding. I'm afraid we have a choice between 1) leaving this mode as it is now, and 2) removing it entirely. Does anyone use borderless mode and thinks it is better than fullscreen in any regard?

Pray for a Linux guru to come and share his wisdom with us I'm pretty sure it is something about Linux windowing system (I guess it is called X, although today it might be Wayland). I'm afraid any Linux player will be more helpful in the diagnostics of the problem than me. Maybe @PranQster could help.

This would be absolutely useless, because there is no support for borderless mode on Linux. It is only handled on Windows, and merely moves/resizes the window by a few pixels.

Maybe it is heatHaze shader? Every postprocessing shader uses the saved texture of the FBO, which is not multisampled, I guess.

Does not help. I even tried to replace this pseudorandom with another one which I used for dither yesterday (sin + fract), it looks pretty the same. This fixes the problem for me. I see no error messages in debug context, no errors when reloading programs. The issue happens on objects which are far enough from the player, so I guess mipmapping is the culprit. Should I capture a trace and look at GL states during SSAO rendering?