vladislavbelov

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.

Yes, I'll commit it after the FF. And we can add materials with more textures. I made few experiments with BRDF on 5 textures (diffuse, specular, glossiness, metal, transmission) some time ago and it works for me, but it needs to tune some params. Do you mean just a glow material without bloom and real light emitting?

Do you think we have/can have many players with OpenGL < 3?

Hm, about transparency, you can try to reduce number of probes for low alpha: make a function like f(alpha) that returns a number, how many shadow texture the shader should do. @wraitii, it'd be good to think about dropping the older OpenGL versions and leave only 3.3+. It's only for low angles. right? For usual playing angles it's not really visible, at least shouldn't be.

Hm, so currently your patch can not be applied as is because of lags. But, we can a little bit optimise it or add an options, which algorithm to use. I'm not sure, that it's the major reason, because for near to perpendicular triangles only a pixel line will be rasterised. I think there is a reason, why it's slower than it can be up to 2x times: many transparent things have a bigger (up to 2x times) transparent area, than it needs. Example: palms. Also did you test shadows with discard-like way? When you don't calculate shadows when the pixel is fully transparent.

How did you check that exactly the fragment shader is most expensive (the grass has transparent things too as mentioned above)? Could you post you profiler.txt results here?

Not only _(), but the Unicode version of the wxWidgets at all.