vladislavbelov

Hi @thekolian1996. The problem is in the translation string, it contains "[" and "]". They are special characters and should be escaped with the slash "\" one. The solution is the translation fixing: https://www.transifex.com/wildfire-games/0ad/language/uk/. I think we need to ping translators and add a check in the translation script. @elexis?

There is a little difference: .pyromod has an additional behaivour. It's associated with the game, zip - not. Only drag&drop works for the zip. And it's not allowed to put .pyromod inside mod folders yet (but it'd be good to have such possibility). So .pyromod is not equal to .zip.

Yes, it copies the mod in the right place.

For pyromod you don't need to know paths, just drag&drop a pyromod file on the game icon or double click on the pyromod file.

The reason is the static element layout:

Yes, @elexis already mentioned this problem, I'm working on it. Look at handleInputAfterGui function in input.js and updateCinemaPath function in session.js.

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.