vladislavbelov

There is a new borderless.fullscreen option in A26, you could try to set it to false. If it doesn't help then highly likely it's not the game issue (maybe SDL).

If you don't render both meshes at the same time (frame) then it's ok. Especially if you use the same material for them.

Answered. In short: we don't decompress data.

I've also added borderless.fullscreen and borderless.window options to the config file. You could try some if it changes something.

Is that screenshot made via F2 in the game? Could you try to switch to OpenGL backend? I also found the following quote from https://docs.microsoft.com/en-us/gaming/game-bar/known-issues: So it might mean that the game bar might not work correctly on some drivers.

A26 profile.txt is also with high shadows, right? A25 profile.txt says that it has everything faster, not particularly graphics (and pretty stable magnitude for mostly everything). There were no graphics or engine related commit after that one. So it seems more related to AppImage itself (maybe some optimizations are missed in the build). Could you attach system_info/hwreport for A25 too?

Could you get profiler.txt for that setup as well?

I see you have set Anisotropic filtering to x16 (which is x2 by default, like it was in A25). Could you switch it to x2 and compare the performance?

Which fix do you mean? There might be multiple reasons (including driver updates). Could you run the game, get 25FPS and press Shift + F11? There will appear a profile.txt file in logs folder, could you attach it here. Also do you have installed A25 to compare?

Stack:

That should be pretty old bug. Magenta happens when you have XML for the terrain type, but not the DDS/PNG texture. It crashes when PMP refers to a not existing XML file for terrain IIRC.

It looks ok. That's strange why the text is encrypted. Seems like XMessage reinterprets it as Unicode or vice versa. Yes, it's solved in r27067 and in the upcoming release as well.

You might find paths to them here: https://trac.wildfiregames.com/wiki/GameDataPaths#VistaWindows10.

Do you know which locale does your OS use?

Could you make a screenshot via F2? Does it contain black bars? Also could you attach your system_info and hwreport (you might find them by paths from https://trac.wildfiregames.com/wiki/GameDataPaths#VistaWindows10)? Is freezing reproducible?

Hi! In the upcoming A26 release will appear an option to decrease texture quality and disable anisotropic filtering. Plus disabling variation randomization might help a bit.

I have some ideas to fix the heightmap import to allow 16-bits grayscale images.

In Atlas you can place entities (simulation objects, units you can control, etc) and actors (just visual objects without interaction). So you can make a 3D model, import in the game as an actor and place on a map.

We can add slow brushes/algorithms to Atlas. And add a heightmap export function. I think using an actor mesh gives the best quality. But it requires an experienced artist to adopt to avoid things you described.

I'm afraid generating good mountains in JS might be very slow, especially if try to simulate an erosion process. Using precomputed assets (like heightmap mountain brushes) might work though.

I was explaining why moving the functions out might increase the code length.

Related bug: #3285

It's more tricky. In a regular implementation peer2peer increases traffic from a single peer and total traffic isn't halfed, usually it's mostly the same as with client-server. Also local state modifications (cheating) and host migration are easy things to abuse.

It's good if used with ranges. It's worth to mention though that MSVC sometimes might not inline lambdas and it might affect performance.

auto indeed saves some visual space, but at the same time in some cases it's less clear and isn't safe. Unfortunately we can't define a set of types that an auto might describe (as in more functional languages), auto is kind of workaround because C++ can't express some things better than with auto, fortunately there are concepts in C++20. C++ compiler verifies auto by used operations not by their semantic meanings. It means in your example we could pass a vector of strings to the reduce function and get a lot of string copies (accounting we don't have const int at the left). I'd like to have something like that: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es11-use-auto-to-avoid-redundant-repetition-of-type-names . And addition or reinterpretation: "Use auto when a type class can be deduced by a reader without much context". Mostly it means prefer a STL function over the same function in a third party library or written by yourself. I'd like to remove the lib and merge its functionality into regular folder as well. Generally agree though the code might be longer because of that. F.e. having a FromDouble function in a global namespace isn't a good thing.