vladislavbelov

It's not so critical as it could be, but it's still UB and should be fixed. But how it may work: How usually (compiler depended) new[]/delete[] work: new[] allocates a block with a needed size + a space for size - a number of objects. delete[] extracts a size from the block and calls a destructor for each object and deallocates the block. But! u8 is a basic type, not an object. So a compiler may replace new[] by new for basic types or use another trick, especially in case all actions are in the same place and the compiler knows a storing object. Also we have own pool and arena for some cases. Not all, i.e. clang-802.0.42 doesn't detect it for basic types (for N5 too), only for objects, even without -O0+. Probably because of the trick above. We had an option for it sometime ago, if I'm not mistaken. It was called --enable-address-sanitizer. It'd good to add a regular (1 per week) build on Jenkins.

I already answered to your post on the habr. But thanks a lot again for helping to find errors. Only few of them are known, and patches are waiting for the end of FF. UPD. I will create tickets for missed bugs, when I'll be at home.

This note doesn't make Javascript nondeterministic. It just means that it depends on an implementation. Because different engines for different types may use different structures behind objects/arrays for more optimal storing. Also this reference suggests to use `for ... of` or `.forEach(...)`, when the order of the iteration is important. But `for ... in` is used for cases, when you just need to change/find a property, without knowing its index (the not fixed order may make it a little bit faster). So Javascript as the language is deterministic.

PBR could make the metal more metallic, but it's more expensive and requires more memory.

Could you attach the exported DAE file? It looks like it doesn't have this point in the right place. You could open your file and any other of the game to compare where attach points are placed.

Skybox is hardcoded, so currently you're not able not change its shape, only textures. But change it to sphere would be good. Also It'd be good to add atmospherics scattering. I have some plans to improve the sky. But the game is RTS, so usually sky isn't really visible, so even a flat sky works.

The same for your resolution, because it uses a power of two, so for you it'd be 1GB too.

When I added these settings I evaluated the high shadow settings on 1080 Ti for 4K monitor, it has 11GB. How many video memory it costs depends on 2 things: settings and a screen resolution. So if you have high settings on 4K monitor, it'd cost at least 4096 * 4096 * 4 * 4 * 4 = 1GB.

You can edit a configuration file, you can find the file for your OS here: https://trac.wildfiregames.com/wiki/GameDataPaths. And add or edit (if present) lines: view.zoom.min = 50.0 view.zoom.max = 200.0 view.zoom.default = 120.0 Cinematics zoom like in SW: Empire at War isn't supported, probably yet. It's not valid for multiplayer, especially rated matches.

I tried, it doesn't work (it does nothing).

Yes, leper suggested few solutions for this. The main idea is to load fonts (.ttf), but not prerendered atlases. Also we need to support system scale (I have a patch for it) to prevent a blurry image. Why there are random lines? Because it's a standard problem for all systems that are simply positioned in DIPs. First of all we need to refactor GUI for it.

As I said before: after refactoring

The terrain isn't transparent and blending doesn't make sense after the blending is done (especially on long distances), so there is no problem with it. Yes, it requires a work, but it's simple. True, as the tessellation one But it's the another level. It can't be faster than simple quads with a texture. But it can be nicer.

Currently I'm trying to add features that popular in modern engines and liked by players to find different implementation bottlenecks in our code. Yes, I mentioned, that it doesn't support many lights per model. Usually video card can support from 8 to 128 lights per model. It uses simple uniform structs (even not UBO). // 8 floats per struct. struct PointLight { vec3 position; float radius; // vec2 - compressed 4 components, instead of unsupported "half". vec2 color; vec2 coef; // Cubic curve coef. }; So we can calculate how many lights we can use from GL_MAX_FRAGMENT_UNIFORM_COMPONENTS. There're 2 import notes: 1) we can use forward and deferred rendering simultaneously (i.e. for different distance), 2) as you noticed we don't have a lot of semitransparent objects; trees, bushes have transparent only for soft edges, so on enough distances we can render them without alpha blending and they're not transparent objects anymore (we don't need to be honest for rendering always; if it looks the same/very similar but cheaper, then we'd can use the cheaper one). If we assume that we don't have a sun at rain, then we'd easily add shadows to the lightnings Nope (at least not yet). It'd be confirmed when it'll be in the our main repository It uses 2D rain texture (drawn by me in Ps for 5 mins ) on many long crosses with double side rendering (because many particles would be slow). They're not moving when the camera is moving. So it seems a correct rain. Current implementation doesn't use shaders yet, but with shaders it can be a little bit nicer.

Another using of lightings:

Nope, it doesn't need it. The deffered rendering can be easily used with transparent objects too.

Of course as option I'm mostly interested, is it useful without shadows for artists/modders? It'd be as option, so you'd can disable it. It's a little bit different technique, the glow effect can exist without lightings. Yep, but it requires the refactoring as I mentioned. So you could test my phab patches to accelerate this implementation You may notice it on clothes on sticks near the bottom house of 2.

I spent last 2 of my evening on the implementing of the addition light system in the pyrogenesis to find implementing bottlenecks for new objects. And I found some places, but that's not the topic. How additional lighting system looks: Fully dynamic lighting. And all light sources can be attached as props (i.e. to bones): "May the Light be with you..." But what restrictions do we have? We have 2 main: The lights can't throw shadows, because performance (we can implement it, but only few powerful videocards can handle it). There can't be many light sources in one place (at least for low videocards and since we don't support deferred rendering). Because shaders have own restrictions, particularly uniform sizes. But probably it's not the real problem. So I have a question: do we need additional light sources in near releases? Would it be real useful? P.S. I found strange normal values for some model, it should be investigated (probably the shader problem).

You wanna say @wraitii. 0 A.D. doesn't have the crowd simulation, only a path finder for short and long paths. You can find it in source/simulation2/, files that contains the "path" word in their names. There are also UnitAI and UnitMotion components.

.zip/.pyromod dropping should work for the Alpha 23. At least I tested it on Windows 10 and it works.

"camera moved" != "nothings was changed". Obviously. And AABB with AABB usually faster than Sphere with Sphere. About frustum planes the math is pretty simple for AABB, you need only 2 dots. Something bad is happening, if you need a complicated math for it. Feel free to add new values to the profiler: https://trac.wildfiregames.com/wiki/EngineProfiling.

You don't need 60fps if nothing was changed. And I don't suggest to fully separate thread, I only suggest a simple worker. It requires much less work from the current state. You need only 2 synchronizations in my variant. Because after the submitting step you have a set of buckets independent of the sim state. Why do you call AABB expensive? It's usually faster than sphere, but usual BB is slower, but not significantly (btw, it'd be good to compare). You have profiler.txt for that.

Renderer shouldn't do this. He should wait, if he has been done his work already. No, it wouldn't. We only need a simple semaphore. Because we need to have a 1:1 running scale. I'm not sure that only visibility checking improvements will save a lot of performance, but the testing will show. Also the hierarchal system should be pretty dynamic without much asymptotics losts.

But it shouldn't be interdependent. Because we need to split it for 2 steps: submitting and drawing. Without threading it would be less powerful, but still useful. Because we don't need to wait until post-processing and buffer swapping will be finished.

As I said, add weather or decrease the current level of the penumbra effect.