vladislavbelov

Besides possible leaks the consumed size of memory depends on many things: map size, game max population, game duration, amount of units, graphics quality. For ex. some games with 1.5hour duration, 2 players and 300 population limit on a small map may cost not more than 900MB.

Sure, what step are you on in the instructions (https://trac.wildfiregames.com/wiki/BuildInstructions) ? You could also write PM to me.

I used it as a first version of a planet procedural generation (not only, but mainly) in project with my friend more than 6 years ago:

Perlin noise? (at least I see familiar pattern of distribution).

If you'd able to get SVN, apply the patch and compile the game then it'd be great (BuildInstructions).

Hi @Drak0 and welcome to the forum! Could you attach your system information (to see how the game detects it)? You may find it at the system_info.txt. Also we have a possible fix of the problem: D1789 (#5412). So it may have chance to be fixed in the next release.

Hi @erickOtakuls500 and welcome to the forum! I suppose it happens on Windows, could you disable post-processing/GLSL in graphics options of the game?

Hi @weridetogether6 and welcome to the forum! Are you able to compile the game from sources? Also could you post specs of your computer? You can find it at log folder: GameDataPaths (wiki).

I suppose you can create an aura and assign it to a special tower. The effect looks like: { "value": "UnitMotion/WalkSpeed", "multiply": 0.5 } I don't remember, did we add an effect after death or not. The mine could destroy itself and give damage for all near enemies.

Cool! I think it'd interesting to add a slowing towers and ground mines.

The sky should work without any problem (even without hacks), but the good terrain is more complicated (I mean without really noticeable artifacts).

Nope, because we don't have a glow pass either HDR one (we increase the brightness only for the whole frame). But it'd pretty easy to add after GL1 drop (if we'd drop it x) ). Could you share a sample of the "oscilating shader"?

Nope I think D1954 shouldn't affect the redness. My patch doesn't solve the whole problem only not rendered blocks (patches).

This is my patch from #2692, it solves water blocks that we didn't render before because of scissoring.

I suppose @wraitii is right, because we didn't fix redness of scissoring yet.

Are you able to reproduce the issue each time (each run)? Also you could apply the following patch and compile the game: diff --git a/source/ps/VideoMode.cpp b/source/ps/VideoMode.cpp index 5cca5fe0d9..9d426f7690 100644 --- a/source/ps/VideoMode.cpp +++ b/source/ps/VideoMode.cpp @@ -246,7 +246,7 @@ bool CVideoMode::InitSDL() u16 ramp[256]; SDL_CalculateGammaRamp(g_Gamma, ramp); if (SDL_SetWindowGammaRamp(m_Window, ramp, ramp, ramp) < 0) - LOGWARNING("SDL_SetWindowGammaRamp failed"); + LOGWARNING("SDL_SetWindowGammaRamp failed: %s", SDL_GetError()); #endif m_IsInitialised = true; And then post the output of the warning here.

Yes, that was an origin point. But it's not a silver bullet. Because the another layer of abstraction reduces flexibility, adds limitations and may reduce performance, because of many differences in backend APIs. We can't just add a IRenderer with methods like drawTriangle. Theoretically you can do this, but it would have a significant performance lose. You may add abstraction structures (like octree for frustum culling) that work for all types of backend. But some backend dependent stuff won't work easily. For ex. shaders, you need to use universal language or use some language converters. Which means another layer of limitations. So, what we could do (not a full list): 1. Use own graphics engine a) Use the only one backend API (like Vulkan or GLES) with some third party libraries (like libangle for GLES) that convert these API calls for other platforms (other than supported platforms by this backend). b) Use multiple backends (like you suggested) with run-time or compile-time backend changing. 2. Use third party graphics engine/library: a) Use a complete game/graphics engine (like Godot). b) Use a complete graphics library that has own stable API with own shader language. In only my opinion I'd prefer the 1a or 1b but with not more than 2 different backends, like OpenGL + Vulkan. Because they're Open-Source and present mostly for all platforms (through third-party libraries). Because it's most interesting for a graphics programmer: you don't need to support a lot of backends and you have enough power of the backends. But! It means that we need to handle some low-level stuff by ourselves. Like GPU blacklists, driver specific bugs (like our Intel crashes), and so on. That's harder to support. Complete engines have own problems too, they have less flexibility/performance or small number of supported platforms (some engines already dropped <= GL2). They may change their license or stop support it. Actually it's not the easy question. That's why I suggested to not rush inside rewriting all graphics stuff (while we somehow support most platforms) and refactor all related stuff first. I think the main task now is to collect and isolate most of GL code in some specific place (not just call them through simple proxy functions). That'd be useful for any way that we'd choose.

It's a good tool. I'm using it for a while. But it still misses some good features from RenderDoc, which doesn't support our GL unfortunately. We mostly use 1 draw call per each GUI element. It'd be good to refactor it and to use only 1-2 draw call per all GUI.

Also can it be the compatibility mode in Windows (where you can run an application with Windows XP compatibility)?

I'm not sure that's in the case. But we have wrong Windows version detection. We can't detect Windows 10 correctly.

Exactly.

It's possible, but much more expensive. I don't think that we will have that until we drop all GL versions less than 3.

Hi, it's possible and it wouldn't be really hurt for performance. I'd prefer to add it with weather and sun. Brightness of clouds or objects really depends on environment brightness: (http://homo-creativus.info/wp-content/uploads/2014/06/IMG_5932.jpg)

Yeah, every function that may invalidate the constant reference is potentially dangerous.

We talked with @elexis about constant references and I gave an example why passing by value may be better than passing by constant reference. During todays refactoring I met another important things that you need to know about constant references. Aliasing Take a look at the following code. Do you see a problem? (It's our code from ps/Shapes.h). // Interface class CSize { public: // ... void operator/=(const float& a); // ... public: float cx, cy; } // Implementation void CSize::operator/=(const float& a) { cx /= a; cy /= a; } If not, would the following usage example help you? CSize size(2560, 1440); // Normalize the size. if (size.cx) size /= size.cx; debug_printf("%f %f", size.cx, size.cy); You'll get: 1.0 1440.0 Because the a references to cx, and the first line of the operator modifies the cx. And in the next we just divide the cy by 1. It may happen in each case where we get the same class. I fixed the problem in D1809. Lifetime Another important thing is a lifetime. Let's take another look at another example (fictional, because I didn't find more detailed example in our code yet): std::vector<Node> nodes; // ... duplicate(nodes[0], 10); // ... void duplicate(const Node& node, size_t times) { for (size_t i = 0; i < times; ++i) nodes.push_back(node); } From first look it seems ok. But, if you know how std::vector works then you know, that on each push_back std::vector can reallocate array to extend it. And then all iterators and raw pointers are invalid, including our constant reference. So after few duplication calls it may contain a trash. So, you need to be careful with such cases.