vladislavbelov

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.

Raster maps inside sparse trees

Do you want to draw on terrain or only to place entities? I think sparse tree isn't bad to place entities, but I'm not sure. Also I already suggested many times to use brushes in JS and do not use heightmaps or direct modifications. I think processing brushes on C++ side may give a speedup. It depends on area. I think it's worse for our case .

I suppose that the first OOM happens because of JS. Also I think you don't need to increase the heightmap resolution, but the texture map resolution. It's possible, but it requires a lot. Because you need to store this information, but the compression is limited. Possible solutions: Megatexture technique (Sparse Virtual Textures). It still requires to store the whole texture (on disk). Also modern OpenGL (3.3+) is needed for an efficient application. Mixture textures or blend textures (a more possible solution for us and similar to Oblivion AFAIK). It requires a space too. We may use our terrain patches and limit a max number of textures per patch to 4 and use an RGBA texture to mix them. Now a quality of paths depends on these textures sizes. For example: 1024 map = 64 x 64 patches, let assume that the resolution is 4 pixels per patch cell (pretty small for smooth details) = 64x64 pixels per patch, 64MB without compression in total for the whole map. A bigger resolution requires a lot more because of square. Also you’re able to store an additional texture as an interpolation configurator to decrease the main texture. Prepared patterns, it's similar to the previous one, but we don't allow a full flexibility of mixture textures. We suggest prepared mixture textures and map makers use them by their indices. Or they add some by themself (but it requires a bit more space). It allows to use 32x32 (1024 patterns per 1024x1024 texture) or 64x64 (256 patterns per 1024x1024 texture) pattern textures per cell. Paths (it's like vector for rasterized pictures), it's good until we have a lot of paths. Its performance depends on number of paths. 2D sparse voxel based terrain rendering, it's pretty similar to the megatexture but in terms of vertices and geometry instead of textures. So I think megatextures are preferred here. These solutions that I remember and shouldn't be hard to map makers. From a superficial look, the third solution looks pretty fine, not much space, not much performance losts. Very likely there're other solutions, but I need time to think and analyze them.

Offtopic, but I have an idea: what if we add semi-supported languages as a mod?

Which wxWidget version is in your Linux? Possible solutions: a) install newer version of wxWidget; b) run it with X.org, not with Wayland.

Multithreading isn't a silver bullet. It requires a lot of stuff: you need to synchronise different threads, you need to pass data between threads and you need code it without races. It costs a lot of time for complex projects, so as Stan said we may not have a visible benefit at all. Or its cost would be really huge. So it should be analysed before introducing the multithreading in all stuff.

<offtopic> Actually 0A.D. uses async/await during its development. For example some of my patches are waiting for other patches that are waiting for review (promises!). At the same time I may create async patches that are not related to the previous ones. </offtopic>

By the way, we have a ticket for autosaving and I even had a patch for this: https://trac.wildfiregames.com/ticket/4417