vladislavbelov

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

Not completely, I saw it when I was testing the patch last time. I need to retest it. Could you attach you map and graphics settings? We'll test the bug and on your map.

It really depends on frame. Try to move the camera for some empty space. Or order all 1000+ units to move. Unfortunately we have only 56% of players who support the GL4+. Also I suppose in most cases GL4+ means Vulkan too. It also gives a lot of opportunities to optimize. We use a lot of space in our VBOs, we don't even use compressing. The most important thing I really want to know from Intel: why drivers crash? (We don't see so many of them for other vendors).

Hi @John and welcome to the forum! Could you post your system info? You can find it at the logs folder: https://trac.wildfiregames.com/wiki/GameDataPaths#Windows

You're absolutely right! I concentrated on the feedback results and politeness to our players and forgot about some entertainment, because we're the game. Thank you!

Thank you for your feedback! One of few means that I'm not alone I'd glad to hear more detailed presentation's fails from you. Anyway I'll try to improve it!

Yes, it's true, but it requires time. I could suggest to install another version of wxWidgets.

I told you about architecture in general, not a certain function. You're right, start point is the frame function. But a lot of details are hidden behind functions inside the frame. The first ticket doesn't look like the C++ part changes. I'm not sure about the second one. But the third one is definitely about C++. It doesn't have breakpoints in a usual understanding. It has assertions (ENSURE), that could be breakpoints for some implementations/configurations. So in this task you need to replace some relevant ENSURE to LOGERROR (not all): https://trac.wildfiregames.com/browser/ps/trunk/source/network/NetServer.cpp.

Have you run a match in the game? Does it work?

Hi @Kam, welcome to the forum! Actually you don't have to make an application for programming. There is a wiki page https://trac.wildfiregames.com/wiki/GettingStartedProgrammers to start. I suppose you already have seen it. Our engine has a popular single loop based architecture. You can follow it in the main.cpp, it looks like: while (gameIsRunning) { cleanupProfiler(); // Common stuff tryStepLoadSomethingIfPresent(); processEvents(); processNetwork(); updateGUI(); updateGameState(); // Including simulation // Rendering stuff prepareForRendering(); findAllVisibleActorsForSun(); renderSceneToShadowMap(); findAllVisibleActorsForCamera(); renderSceneToScreenBuffer(); doPostProcessingIfEnabled(); renderGUI(); swapBufferToRealScreen(); // End of the frame recordProfiler(); }

Could you post your system details (OS, its version, CPU, GPU, etc)? Did you compile the Atlas or you use the packaged one? Which version of wxWidget do you have? From first look it seems that it's a problem with wxWidget.

It also requires a visual comparison. Are they visually equal for all distributions? I think we can just move fonts. Because currently we don't even need them on user machines. The important step is the font rendering - to use real fonts instead of prerendered pictures. And on this step we can decide how to distribute fonts.

It mostly works for software that tries to looks like the system one or with similar controls (the same design for the whole user system). But it doesn't work always for custom designed applications like the 0 A.D. game. A new version of a font could look worse with the current in-game background. So we should account it too for the removing. Though we don't use fonts in real-time, but we plan.

Also could you attach here your system info from log paths: https://trac.wildfiregames.com/wiki/GameDataPaths?

Currently we have no such ticket. We can easily add additional layer of skybox, but there should be a smooth transition between sky layers and map. It's a problem with the additional layer. A possible solution is to use a big low-poly terrain that's scaled up, like it's done in Half-Life 2. It's easier to make a transition, but a simple model won't work for different sizes of random maps. Usually players don't see horizons at all. Only in cutscenes or trailers (where we can use some hacks to reach the goal). So it's in my list, but not on the first place.