vladislavbelov

Hi @framodan and welcome to the forum! There is a common problem about compilation with Unicode on Linux: https://code.wildfiregames.com/D1202. Do you have other errors?

I mean mod's requirements, like "0ad=0.23", not real mod versions. We change many things between releases. So I think modio have to allow to play mods for players with older versions of the game.

Is it possible to have different versions of a mod for different versions of the game?

I think so too, but I have few suspicions, so it can be the same or a kind of the same. Or it can be something unrelated.

Could it have a little more details? It shouldn't be hard.

Did you mean that we don't patch releases?

How did you do this? With the monitor buttons or NVIDIA panel? By default they use DirectX, you need to go to settings to switch to OpenGL.

I've searched for the issue and I found only links about wrong drivers. And most solutions are update Windows and update drivers (or downgrade to the old one, where OpenGL works). Also as I can see you have 32bit, not 64bit OS. Our game doesn't initialise OpenGL directly, most things are done under SDL library. Do you have other games, that support OpenGL (i.e. Half-Life 2)?

Also I can recommend to update drivers for the motherboard and the integrated Intel card, if they're not already new.

Hi @Devilsknock and welcome to the forum! Could you attach crash dump too? We know about the wrong version detection, we'll try to fix it to the A24 release.

In some cases it's pretty hard to tell that a mod breaks IP laws. Because we need to check all data, find its sources and check licenses to be sure, that the mod doesn't break IP laws. Even steam may sometimes publish games with broken IP laws. Another side is different IP laws for different countries. So I think, the possible solution is to check mod only for basic and security things, and remove the mod/make an investigation if someone reported about broken IP laws.

I mean changes that lead to the bug with blue edges.

It's not actually true. GUI support stretching by setting a size in percentage in XML. A more complicated logic can be implemented in JS. But it's not easy and pretty hard to maintain it. So, I can say, it presents, but it's not ready to use freely. Could you post your changes for this? A color set.

@Shiyn 1. Is it possible to make the palette a little bit warmer? 2. Is the bug from your screenshot reproducible: ?

Yeah, I definitely agree with that. And I think the 1024 width is enough to use for a while. I worried mostly about the scale for the engine. Because we have issues with that: 1) we don't support scaled fonts yet, 2) we don't support system DPI, no DPI aware yet (i.e. Windows on 125% just scale the game).

I mean, doesn't the Fedora support the screen division in a different proportion? And why you don't use a lower scale, i.e. 1.5?

Is it possible to change proportions?

What OS do you use? And why the effective resolution is lower than 3840 / 2?

Are you sure that exactly fog costs much? It requires amount of free video memory.

Implementing LOD for the current renderer arch will be a little bit hacky, so to go to LOD direction we need to improve the renderer, as @Yves mentioned some time ago.

Geomipmaping or ROAM itself can't make art too, but it provides an easy possibility to do it. Tessellation not only smooth, but it can make sharper or whatever the original model was (yes, it's hard to make the same sharpness as for geomip, but it's possible for the geometry shader). It's expensive, yes, but it's possible to add some art things in the tessellation too. Just add a texture with a variable density. More complicated things are possible in the geometry shader. So GPU can do the same things, but with a different cost.

Yeah, and it works good, but it costs the bandwidth. But I like it, it's simple and pretty effective (as most of tree-based optimizations). As a just possibility example we can pass the only one quad and the heightmap texture, the rest of work will be completed by GPU on the tessellation step (don't know how much it's expensive, but for something like GTX 1080 it should work good ).

Yeah, go to 4.0+ is too fast for us, because we want to support usual players too. Not sure, it'd be useful for the terrain, but it's not necessary. For old cards - yes, for new cards - it works. At least some AAA games/engines support the tessellation.

Nobody was talking about it. I'm talking on a higher level, about a choice between multiple renderers (modern and legacy) and single renderer (that supports most of popular videocards), about the renderer architecture at all. With good architecture we can support multiple renderer very easily. But we don't have one (probably yet). But do we really need it? I.e. OpenGL 3.3 was released in 2010 (8 years ago) and is widely available these days, so why not drop OpenGL2 and go to OpenGL3.3 (why 3.3 and not 3.0, because it's nearest to 4.0 for old videocards). There is a problem, that we will always have a modern things and legacy things. Probably not so hacky but still (i.e. GL3.3 vs GL4.0 for tessellation).

So it needs to test how it works and looks and then discuss with artists. There is a complicated task to add a new OpenGL support (btw one of reasons why we need the actual feedback statistics) without dropping not real old cards. Also we have a GLES "support", so probably we need to count it too.