vladislavbelov

I think the reason why we need it - increasing realism of the game picture. We don't add effects for effects. If you want to make it very noticeable, you can add it for any graphic benchmark. Currently penumbra effect is too blurry in comparison with real life IMO.

Yes, you can How long is it loading for you? The brush seems not hard to implement. Let's see after the FF.

Why? I'm working mostly on Atlas, Graphics, GUI and Renderer components. It's not so much I think Also my CS works are about a procedurally generated content and big landscape rendering.

Probably it should go together with the "Weather" option. Yeah, obstacles should be far away to have such blurry shadows. Or a pretty cloudy weather. We have @wraitii and Phillip. I'm not active currently in the renderer (I hope I will), but I review patches for it. So all graphic improvements are welcome

It's the common problem for GUI, because we don't have dynamic layout yet (without JS). But I hope, we'll have some basic things for A24.

Ok, let's see inplace. I agree to avoid such things. As I said, structs are mostly used as PODs, but it has different usings, that allow you to write less code and less make errors. Constructors and methods calls Sometimes you need to pass many params to constructors or methods, and pass them directly may lead to errors and a unreadable code. Without struct: class TextureManager { public: TextureManager(size_t cacheSize, bool preallocatedCache, bool generateMipmaps, ...); }; // It's pretty easy to forget and swap bools here. // And the call is pretty big. You need to add comment to everyone, // but it will break after an order change in the constructor without // compilation errors. ... = std::make_shared<TextureManager>(10 * MiB, true, false, ...); With struct: class TextureManager { public: struct InitParams { size_t cacheSize; bool preallocatedCache; bool generateMipmaps; ... }; TextureManager(const InitParams&); }; // It's easy to catch missed params. TextureManager::InitParams params; params.cacheSize = 10 * MiB; params.preallocatedCache = true; params.generateMipmaps = false; ... ... = std::make_shared<TextureManager>(params); And much bigger production example: https://cs.chromium.org/chromium/src/ui/views/widget/widget.h?sq=package:chromium&l=149. Function results and grouped members Sometimes function should return more than value, popular way is add ref/pointer params (it's pretty fast, but more symbols and the same problem with number of params). But with struct it can be solved shorter. I.e. std::pair is struct. Without structs you need to write a getter for each property, and sometimes these properties don't need to be access and store separately. Example: our Material class. With struct it allows to use only one std::vector to contain params. And there is no needs to use classes, because the data is pretty simple.

You said about the technique at all, that it only work for low angle changes. But there're imposters with 3D textures (not shots from different angles) too, and they don't have such problem. Obviously it's more expensive, but not so much as an original hipoly model.

Did you ever use imposters with not a simple texture? I only may suggest you to play on the big Jebel-Barkal map. And I'm not even talking about cinematics.

True, it's the very popular technique, but it costs memory (there're also some nuances). There are few ways to blend 2D and 3D nicely. So we can try it too, at least it's possible to implement it for the pyrogenesis.

I suppose it was Z-fighting. We use mipmaps for textures, I don't think, that it's called LOD.

I think, @aeonios tells about all videocards that we support (OpenGL 2.1). It's always possible to add a support of modern videocards, but it requires an additional code. I.e. my desktop renders 0 A.D. on High with 20+ millions of triangles with 30fps on high resolution (so with optimizations it'll be even faster), but my laptop - only 1million with 30fps or even lower. So for many users it's pretty expensive, but for players, especially very active players (playing in modern games), it's cheaper.

Oh, sorry, I misread it. I wanna try to render many tries without art changes at far zoom and lowest angle (with camera constraints), when camera is on a hill. Currently tries are animated in the vertex shader, hopefully it can be improved with cooperation of artists, because we can add specific information inside vertex attributes. Also we can use a wind map instead of const wind data.

Ok, I'll try to use only 2.1. I'm thinking about a case when all tries are drawn. We're working on it, I really hope we'll have actual statistics for the game.

As I remember, it was GL3.3 compatible. But I'm may be wrong, it was quite a long time. I wanna write some hacky things for GL3.3 to reduce number of drawn triangles for tries. It'd be good, if you'll be able to test it. Btw, what videocard do you have? It's very interesting sentence, because we don't have actual statistics for the game. And I didn't find real world OpenGL statistics with a large sample (mostly few thousands). There was something on Steam, but currently it doesn't show OpenGL for me. I absolutely agree to reduce the number of triangles, if it won't be noticeable. My point is only about noticeable changes.

LOD for model, not for terrain. We can introduce it separatelty. Try Yves OpenGL4 branch, and you will see, that it's not a problem to show many tries. With LOD it'll be even faster. And with few other techniques it'll be stable 60fps. So I don't see a problem in current models with using right things. P.S. It looks like 3+ million of triangles is pretty normal for modern AAA games.

You can use the wireframe mode to see actual triangles, if you didn't find it yet. I think the current version of tries shouldn't be removed, but can be used as LOD0. At least for close cinematics our tries (and not only tries ) aren't ready, they need higher details and textures.

Vertex structs don't have such data and they don't need to have init(). I can't agree with that, for me it sounds like the + operator is bad in an OO language and you should use add() method instead. PODs are used for simple data without special ctors, and you don't need to add and call ctor and/or many setters to initialise the data. I.e. PODs are easy for using as vertex attributes.

It won't be easy to change the core lib. Also do you have strong arguments, why SFML is better? I had used it only few times, so I found some posts (SFML vs SDL): https://www.reddit.com/r/gamedev/comments/44npzz/sdl20_vs_sfml2_in_2016/ https://www.quora.com/Which-one-is-better-SDL-or-SFML http://www.cplusplus.com/forum/general/190688/ People prefer SDL for rendering and low level things, that needed for us by obvious reasons.

Are you sure, that you're talking about C++? (It seems true for C#, no?) struct and class are the same except only one case: default members/methods and base access. Inheritance it's the same. Struct are used as PODs, but they can have inheritance, virtual methods, explicit ctors and other "class things". Compiler optimizes classes and structs equally. If there're virtual methods (vtable costs, but last time not so big as earlier) and/or inheritances, it'd be a harder work for compiler for both. I'm not sure, that I'm understanding you correctly. Structs are used as PODs. Subtypes are usually needed to have a shorter name, do not create an additional useless class file for a small struct and logically splited types. Compare: class TextureManager { public: struct InitParams { ... }; TextureManager(const InitParams&); }; And yours: struct TextureManagerInitParams { ... }; class TextureManager { public: TextureManager(const TextureManagerInitParams&); }; For me it's useless to make them globally visible.

But it's easy to add as I said. True, and materials use shaders, so we can add additional requirements here. Why not only shaders? Example (abstract), a shader uses the texture reading in the vertex shader from the material texture. But if it's not supported this texture isn't needed. So we don't need to load this texture. Shaders don't manage this kind of flow, but materials do.

Ehm? I didn't say anything about the current state. Hehe, instancing may change batching very well. But I don't want to say many words, it'd be good to analyze solutions when they will be ready. What's the bad? Do you know difference between struct and class? True, it should be solved.

I definitely agree with that. But currently engine isn't ready to easily introduce major version dependencies. We'll get a spaghetti code or even performance regressions. So it needs to do it carefully.

It's not actually true, engine checks versions, but doesn't use it widely. I.e. we use VBO (AFAIK FBO too) only if it's supported as extensions. Also shaders uses "requires" and fallbacks, so it's pretty easy to add switching between real versions of GL for shaders. But the engine needs improvements for it. It exists, and it's called ANGLE, i.e. it's used in Chrome. But it's pretty limited as all universal instruments.

For better quality - both, but for simpler results the shader is enough.

True, but we have old and Intel video cards unfortunately, also many users may not update their drivers. We're working on actualising feedback statistics, but it's not enough to decide about supported versions. Because we also have potential players, who didn't enjoy this amazing game yet or didn't send statistics. I meant to calculate a end pixel shadow color with different number of probes that depends on the alpha value. It's not exactly what did you say about, but just a near idea. Because for more transparent pixels we can have a lower quality of shadow, because it's less visible. There're many reasons to have so number of draw calls.