vladislavbelov

Multi-threading has own overhead: more complicated code (may crash and dead-locks) and time to sync data between threads/processes. So it needs to be very carefully. Btw, I have some ideas about a threaded rendering.

Hello @jeffnz! First of all, I shall recommend you to add a Reamde file with a description and instructions how to compile it (i.e., you need SDL to compile). Because currently it's just a set of files. You could add Code::Blocks .cbp files, CMake file or Makefile, any what you want. Also it'd be good to have few screenshots, as you want to share the game. I can suggest to read http://lazyfoo.net/tutorials/SDL/, it's has a good code style enough and basic SDL principles. Also it'd be good to have knowledges about the game architecture at all: http://www.gameenginebook.com/ (on Google Books), or something like that.

Hello! Did the compiler build something or it crashed after start? Also, do you have enough memory for the compiler? Did you try to restart studio, computer?

Fixed in rP20382. Thank you for the bug report!

Aha! Thank you! I've missed the Renderer.cpp changes in the patch (initialisation mentioned by @stanislas69). I'll fix it at the evening.

I could suggest to make broken foundations be clickable, then select it and press repair. Then the position will be restored from the previous one. Or use alignment, when you move a new wall near the old one, it auto attaches to this place.

I have thoughts, that we shouldn't just rewrite the engine, I think, we need to make an interface, and then implement it for different renderers (OpenGL 2, OpenGL 4+, Vulkan).

Yeah, it seems right.

@fcxSanya helped me with this problem:

Sorry for the long answer. Have you set the FPS throttling in the options? Because the main menu is simple for a graphic card. Also do you have any other running applications?

I've made some stuff, and it works, but it has hacky code, because we don't have a clear way to add custom matrices. So, I need to refract & test it. I think I'll post a diff to phab after refractoring to someone will be able to test it too.

I think it's possible, at least it shouldn't be hard. Because we just need to change the projection matrix. There are few corner cases with culling, but I hope they're easy to solve. I'll try to do some stuff.

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());