vladislavbelov

The setup is quite well compatible. So I can suppose that it could be: 1) huge monitor for this setup, 2) driver issue. I think the full log have a chance to help.

Looks like an out of memory. But could be something else. @Andrej, what's your PC's setup? CPU, GPU, etc?

But you answered on the post above, which reports about performance at all. Not about graphic only. I mean, it absolutely right to improve graphics too, but do not forget that it's not the only one thing that slows the game.

I agree that it costs a lot, but not so much as the pathfinder. Instancing, deffered rendering and batching will help a lot.

@Sundiata @stanislas69 The rendering isn't the issue. Pathfinding is the bottleneck. As you could have noticed, lags are appearing on many units 200, 300, 400 are moving. But for GPU it's not a problem. Problem for GPU is 10000 or 100000 units. The hard thing is to have a compabililty with old GL (2.*, 3.*).

We don't use memset/__builtin_memset directly inside CInput at all. So it looks like a compiler issue (wrong message or something else): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095 It looks like the compile can't follow some call stack. We use threads/events in Atlas (to send between wxWidgets/Pyrogenesis), so the compiler can't find a place where the var was really initialized. By the code there is only the one place where it has assigned AFAIK.

It looks like you have enabled -Wimplicit-fallthrough in GCC/Clang. And to prevent this, you need to add a comment like or disable the option: case 0: ... // fall through case 1: https://stackoverflow.com/questions/45129741/gcc-7-wimplicit-fallthrough-warnings-and-portable-way-to-clear-them https://dzone.com/articles/implicit-fallthrough-in-gcc-7

We don't use DBus in a direct way, so the issue could be in the system configuration, drivers or libraries that we use. But I found few same issues (not really depended on the DBus using): https://bbs.archlinux.org/viewtopic.php?id=227587 http://talk.maemo.org/showthread.php?t=34918

So probably the issue is in the system/drivers and not in the engine.

Because you need to enter "rgb(140, 140, 140)" and not "140 140 140".

Could you reproduce it? Which are you doing?

Currently we don't support remap for the Atlas. So if you want to change a key, you need to download sources and build the game with Atlas. About if you may build, it's in the source/tools/atlas/GameInterface/Handlers/CinemaHandler.cpp.

Are you sure? It looks like it crashes in ENSURE(0 <= pass && pass < (int)m_Passes.size());

Which line it crashes? And it's assert or access violation?

11. No, you don't need to change something, it's ok that some parameters are not used. I want to make some modifications for the shader system, but it's in future. 13. As I said: And not for USE_SPECULAR.

5. They are. 6. No, we shouldn't because materials isn't a bottleneck. 9. Yes, it could be renamed I think, because is uses normal map as usual. But in common terms bump != parallax. 10. USE_HQ_PARALLAX and USE_VHQ_PARALLAX aren't used in shaders, so you could use it only if you add it (and add conditions) 11. If a material requires something and engine doesn't have it, then the material should be applied. Currently there could be a warning or crash, I don't remember. 12. No, it shouldn't, it's different things, normTex is a normal map, which could be used for different goals. And parallax just can use it if needed.

To answer I'm using shaders sources and my additional knowledge. USE_SPECULAR requires specular power and specular color. No, because USE_SPECULAR works without specular texture, but USE_SPECULAR_MAP with, also USE_SPECULAR_MAP requires specular effects. No, because effects are available only for USE_NORMAL_MAP, USE_SPECULAR_MAP, USE_PARALLAX or USE_AO. <required_texture name='specTex' define=''SPECULAR_MAP"/> is better, because you define connected things together. Where from comments? If materials, I think no, because it allows faster fix/add/improve shaders. No. It uses for conditional alternatives, i.e. basic_trans_ao.xml, if quality < 2 it switch to basic_trans.xml. Also it could be used when the material can't be supported, but it's not used, if I'm not mistaken. It's used for the triplanar texture mapping (vec3 instead of vec2). Currently It's used for the terrain. sim_time just a time since the game started, it's used for the water rendering (waves, etc) and for the wind animation. Where? It's not used in materials. I don't think so, only if add conditions. Yes, it's required.

The game session GUI code is in "binaries/data/mods/public/gui/session/". There's a "diplomacy_window.xml", it describes how it looks like. The code hides this window is in "menu.js". How phase handling works you could see in the tutorial script "binaries/data/mods/public/maps/tutorials/starting_economy_walkthrough.xml".

I could describe how it could be in common words: You started a new phase, like usual (no changes) Phase ended, you added a listener/handler on the phase end, it's just call an open function (the same like a diplomacy button call) User takes a choice, press button apply, you added another listener/handler on the button click, which applies changes to the simulation So you need a XML-code for the selection window, JS-code for the phase handler and the button handler.

I think it's possible, because it's just a window which could modify simulation states. Look at the diplomacy window, what's the different? They're near enough. The JS simulation part is flexible already. So you could do many things in mods, but yes, you need to write a code.

Then I think we could not the whole path caching, but patch version. Currently terrain is split on patches. So if any path goes through a patch we could cache it in this patch. Why not the whole path, because usually one piece of a path was changed and many paths have a common subpath. Not sure, just ideas.

Cache could be good. What we need to do when paths and/or obstructions are changing often, i.e. on a battlefield we always correct paths. Won't it add a visible overhead?

Much worse? What does it mean? Currently I'm looking at the format and see that it has the fragmented input and many time for parsing. It doesn't tell me something, that Godot supports it. Because it's not used for really big projects (AAA, AA), at least I don't know about it. I agree that installing addons it's useful, but not necessary, because even with the best addons you won't be a pro. Btw I don't tell that it's bad format, no. It could be really good. Just I need tests, benchmarks, results (numbers), but not words. So I wrote why changing the format is really complicated task.

Yes, but did you read the original post? It's JSON based. Did you use blender? It doesn't support it by default, but with external addon-s we could add any other format.

It's like: This format have pluses and minuses, i.e. Blender doesn't support this format. If we should change the format, why we should use the text one or mixed (like this this)? We could use something faster, most binary formats are faster and smaller. But yes, most of them have a license which we can't support. Also converting is the really much cost operation, because we should convert not only files, but wiki, parsers (a lot of C++), tutorials, probably we should add some hacks for this format. Do we really need to change the format? Because we don't feel bounds of the Collada so much, because we use it pretty simple. Another way we could use assimp, and we won't longer be depended on file formats.