hyperion

How the ancients used white in architecture it's unreasonable that the ground is "whiter" than the CC. While the ao might have improved I guess it also highlights the need to fix base colour. To really give an answer whether I share @Stan` fear you claim please provide all your changes as a single patch against trunk or a mod to play with.

Using a vcs there is no need for zip backups, but using a vcs is probably also the reason why this hack got introduced ... As long a releases are not years apart everyone is patient enough to wait for the next release. Edit: something went wrong when submitting the post

If you have to touch a lot of the assets for this it might make sense to go further. Not saying you have to or that what I'm going to throw out is the way to go, just that I think it's worth discussing. Once more I'm not a graphics guy nor artist. PBR came up earlier in this thread. Maybe it's worth considering adding a prefer spirv option analogue to the existing prefer glsl one. Sticking to glsl 4.6 for the time being is fine. The idea is to reuse this shaders for a future vulkan renderer. This set of "pseudo spirv" shaders can assume modern hardware and drivers supporting opengl 4.6, respectively vulkan, and the goal is PBR. Then while fixing the assets convert them to glTF which lends itself to PBR and has likely better support and for sure better interoperability than the discontinued collada. If this results in some degradation in visuals for old hardware I think that's fine. If you already run on ultra ugly settings like no shadows and simple water some colour skew hardly matters any more. The main question probably should be if there is someone/few capable and willing to do this and whether the artists are fine with PBR and glTF

The latest shaders actually look like a slight improvement, however, just as you said, whitish textures need fixing now.

I listened in on it once more with full attention and disabled music this time. There are one or two hack sounds in there that aren't bad actually. Just that those off ones are far more noticeable. I'm not good at describing sounds so I searched for a reference for how it sounds when hitting with an axe actually gives a result, see video at 5 minutes in True, but throwing javelins doesn't make any sound at all either. Artistic freedom it is. The current stone fx sounds like a pike hitting on granite which I like but feel free to change it.

There was a clear difference, thou it neither looked real before or after. If I had to describe the difference it's moving an arcade landscape from Europe to Africa, less humidity and less distance for light to travel trough the atmosphere. Will test your latest changes later.

Yeah, that would improve things by a lot. Stone sounds rather good, metal not that bad either IIRC

The one for gathering wood is the only one I noticed to be completely off. Like two wooden sticks used as an instrument as a beat in a track. When it sounds like this you certainly wont cut a tree within a decade. There are sure quite a few sounds to get used to, overall the quality of the sounds seems better.

You also need to take out "v_normal.xyz = normal;" of the conditional in the vertex shader for the program to link. Well, tested on a few maps, still looks ok, can't say better or worse, but then again I'm not a graphics guy.

Here, trailing spaces on empty lines, eg. line 59 and 171 in model_common.fs. Don't know what editor you use but should be configurable to at least highlight those. Also git will yell at you.

erm ERROR: Failed to link program 'shaders/glsl/model_common.vs'+'shaders/glsl/model_common.fs': error: fragment shader varying v_normal not written by vertex shader ... and both shaders have white space errors added

going by the calculation of the scalar of Multiply() it's safe to assume length of u being 1. So u being a unit vector is in all likelihood true. Thou there is no v in your excerpt. radius of structure + gap + radius of unit, how is this not adjusting length of u (assumed to be 1) to the distance between centre of building and spawn point? In vector math a rotation is a matrix multiplication. How it's implemented is not that important. In the special case of 3 dimensions quaternions can be used for simpler representation, different performance characteristics and being less susceptible to rounding issues. More or less code is really not relevant. In case of 2 dimensions even cleaner than quaternions is using complex in polar form, ie. multiply with e^(i*scalar_in_radians). The expression in Rotate() having PI there suggest it evaluates to scalar_in_radians which is sufficient to describe a rotation. yes, u is being rotated, u' being scaled and pos translated by u''. pos should be the centre of the building and pos' the spawn point of the unit. The comment suggest that there was some partitioning of the full circle happening before and how unwinding is done here, with some gibberish around it. At least that's how I read it.

A vector is a tool which can be used to describe a position, speed, impulse, force, spin, translation and whatever else I haven't mentioned. There is no position without a frame of reference. You use the term point when in fact you mean position, location (less formal) and to a lesser extent cartesian coordinate. Two vectors can be added to describe the translation of a position. Multiplying a vector with a scalar is still a vector. As for your question, without checking the code: pos is a vector as is u, Rotate is a matrix multiplication denoted by a scalar for the the normal vector, Multiply is a scalar multiplication denoting the scaling of the vector. pos += u is the translation of pos (denoting a position, likely the center of the structure spawning the unit) by u'. Yes, the comment is sub par.

Was done. But apparently it costs too much performance doing that see https://code.wildfiregames.com/D2936 An option to removing projectiles immediately and removing corpses as soon as the falling to ground animation is played is sufficient. Some people are even willing to disable shadows which is far worse from my point of view. This is fine as a brute force method, perfectly fine to ignore the I want to see exactly 362 corpses and no more crowd. Though removing the thousands of pebbles no one sees in large scale slinger battles might make sense for everyone. Too many users would not be able to play the game anymore... It might or might not be early for requiring vulkan. However it would anyway take a year or two before 0ad would have migrated even if you started right now. If someone was willing to take up this task I'd suggest you welcome it whether ifdefed, runtime switchable or straight transition. This is a game about ancient warfare and not ancient hardware. Also there is quite a bit of work that can be done towards vulkan while still using opengl. Unit pushing (D1440) does something like that in a saner manner, but it needs a lot more work to be mergeable. Nice idea, though the units gathering in the video look hilarious.

Some ideas: Option to disable rendering of corpses and projectiles on the ground. Not rendering possibly thousands of objects likely helps quite a lot. Render very low poly replacements at a certain distance. A thousand tris for something the size of a few pixels is not worth it. Option to allow rendering at lower resolution and then scale up. Probably rather useful for 4k users. Use of vulkan instead of opengl. Decouple observers, if they can't keep up it's their problem alone. Possibly move some components to C++ to increase execution speed and to reduce interaction between native code and interpreter. The latter probably is a major bottleneck in 0ad. Sure this reduces the ease of modding to some extent. One I don't like to see personally. Let units have no obstruction so the pathfinder has it easy.

Ha, let's introduce a tech "armour polish", faking increased stats.

Yeah, good point. Maybe make it part of the bribe mechanic to get this info.

If the stats in this screenshot fully represent the unit, then the underlying model is simpler than 0ad. In that case it sure is nice to get away without click to see stats. I just think displaying half truths is worse than click to see. What we can also see here the gui is optimized for 16:9 FullHD.

The right panel is currently 10x4 icons and could be changed to auto collapse if not enough space to 4x1 each of the 4 opening a submenu - preselect, build, research, train. Not saying this is the best solution but at least the room argument would no longer work. I fully agree with you that the preselect actions should be available via gui by default in some way. About the resolution of 1024 × 768, the last time I bought one of those monitors was in the 90'. Rather than absolute pixel one should consider screen format a primary concern and have properly working scaling in place. Armour are currently 5 values - hack, pierce, crush, fire, poison Worse for attack, even without weapon switching - hack, pierce, crush, fire dmg, fire interval, fire duration, poison dmg, poison interval, poison duration, range, attack interval, counter boni This obviously won't reasonably fit. My take, instead of showing half the truth better to not show at all. For beginners I'd say those numbers are rather useless. Far better to have a page which roughly tells in prosa which unit to use for what purpose. Numbers only start to matter once you can play somewhat competitive and have a good understanding how those numbers interact, but by then you likely already know them by heart. I know there is no definitive answer how to go about it and I appreciate that you take the time thinking about how to improve the current situation which is tedious and difficult to say the least.

Why limit yourself to the current panels? Putting preselect actions into a separate one probably beats stuffing them into the right panel which is already overloaded for different purposes. As they all have a hotkey attached it might even be desirable to have a menu option to not display said panel at all. About numbers, there are to many for them to be listed all. So except for the most important and dynamic ones like resource carried the rest is probably better hidden behind a redirection like a tooltip or pop-up menu and the gained space used for other things or given back to the viewport.

I had no issue with the Romans, haven't tried with Persians. So I'd say same issue. Likely cause: non square obstruction

I can simply bind the hotkey to send SIG_STOP/SIG_CONT via window manager, so I'm fine with postponing. But then please add the screen saver inhibition thingy to the TODO list.

I see, well, pausing the simulation and explicitly pausing the game are strictly speaking not the same. Never relied on background pause, so personally don't care Well, the phone call could also be an internet call, was just making up an example here. I don't use pulse by the way.

Over the house coloured red, seems built-in screenshots feature ignores cursor. Haven't even noticed.

Hope a screenshot will do, no recorder installed on this machine.