In D1437#129985, @Angen wrote:

Random thought:
How hard it would be to disable level of shadows and higher on which it errored and force one level lower?

In D2143#89462, @wraitii wrote:

Should be doable by having the darkness of the reflection affect the fresnel. A problem is that reflection should be seen as additive, where as right now we mix both.

Your solution is honestly probably more correct. I figured out that the issue was due to translucency, although I still haven't figured out any way to get realistic levels of contrast in the reflections. :\ Real reflections tend to be very high contrast, particularly wrt shadows.

In D1501#85736, @smiley wrote:

typo. 8 -> 18

Oh. In that case it might be worthwhile to do more tuning with early exit, and possibly find the optimum value for using RangeOp.

In D1501#85734, @smiley wrote:

It helps, but the best I achieved was 8 seconds on 512 8 player mainland. You might have better luck with nani's patch.

8 seconds vs 30-40 seconds is still a huge improvement.

In D1501#85713, @elexis wrote:

The object-oriented programming should not be hidden from the author, the author should rather become used to it. It's one the core design aspects of the rmgen system to be able to use different prototype instances implementing the same interface interchangably.
Yes it requires typing some more characters (new AvoidTileClassConstraint() vs avoidClasses()), but the alternative means spamming the libraries with random proxies.
The mapscripts should be as easy to write as possible, but not at the cost of introducing proxies in the library. The library should be as concise as possible while maintaining its features.

My preferred language is java. :\ I still prefer the factory methods in this case, but I guess I don't necessarily have to do everything in rmgen. An alternative library seems like a better option at this point, because we're definitely not going to agree on very much.

That 6s performance is achieved by nuking the 27 already IIRC

Do what?

Replace the number 27 with 0 in TileClass.js so that RangeOp is always used

Ok, I can pretty much guess what that involves. Seems like an easy win. I bet that early exit could be used there as well, but it'd need similar tuning to ensure that it's only used where it's likely to be profitable. On the other hand, the difference with early exit only seems to be fractions of a second when using RangeOp so it's probably not worth the effort. :P

In D1501#85699, @elexis wrote:

• TileClass is to be changed more deeply, it's on our radar and there are various patches floating around

such as?

• the library.js functions would be better moved to the constraint constructors IMO (new AvoidClassesConstraint)

The main reason I switched things around the way I did was to cut down on verbosity. You no longer have to type "new" all the time and instead of typing "AvoidClassesConstraint" you just type "avoid:". That's also why I made them constants, because nothing is a bigger PITA to type than freaking quotes.

(First two is from a significantly optimized tileclass system)

That 6s performance is achieved by nuking the 27 already IIRC

Do what?

In rP22310#33794, @vladislavbelov wrote:

Partially because of scissoring #2692, but also we have inaccurate refraction projection (inaccurate in relation to the real refraction angles). We may calculate it more carefully.

There really isn't a better way of doing that. Any given approximation of refraction isn't going to be much different from what we've got.

In rP22310#33575, @Angen wrote:

actually it is water refraction effect causing it so now I am not sure if it exactly the same thing but it is red

In D1501#80203, @smiley wrote:

If you've got a way to dramatically reduce that and it proves to work then it's practically guaranteed to be accepted.

https://youtu.be/uCGD9dT12C0

In D1501#80201, @smiley wrote:

Agreed. I just wanted to see the point and purpose of doing things. If you think anything fruitful can come out of the endeavors, then great. I just don't think so.

Are you kidding me? Slow map loading is a major problem with the current version. If you've got a way to dramatically reduce that and it proves to work then it's practically guaranteed to be accepted.

In D1501#80194, @smiley wrote:

You should submit this.

You have done far more valuable things. I guess it doesn't matter if they are here or on a local machine.

It's not a competition. Heck, this patch is mostly about increasing convenience and consistency, the performance bit was just incidental.

In D1501#80184, @smiley wrote:

Yeah, I found the 6-36 thing hard to believe too. Way less and faster iteration and way more efficient cpu cache usage might be the reason. The significantly JS typed arrays would have something to do with it too.
Anyway, we are now speaking of things which does not matter.

You should submit this. Seriously. Going from 36 to 6 is going from O(n^2) to O(n).
What I don't understand is why early exit is performing worse on certain things. :\ It should generally lead to fewer iterations or else have no effect at all.

Yes, there is currently no need for finding the exact number of points in a radius. But a density constraint may not be the only use case. Smarter coordinate picking for random placers could also be a thing.

They wouldn't be very 'random' then, now would they? Doesn't matter, if there's a good use case for it we can just write a function for it. No sense having the feature for uses that don't require it, particularly if it costs more.

But, I guess if it helps, there is no reason to keep dead code around.
(my words don't have much influence. Take what I write as more of interesting fact of the day or something)

I prefer examples to words. :P

In D1501#80080, @smiley wrote:

I just wanted to point out that the changes to tileclass is unneeded and only removes a possibility. The chance of someone needing to count the number of tagged tiles within a radius is not that far off.

I see what you mean here. I mean I guess you could place things based on tile class density, but the current usage only uses geometric measures. If there were an actual need for that we could just add extra functions for it.
At the moment I don't see a real reason for using density-based constraints though.

In D1501#79925, @smiley wrote:

(First two is from a significantly optimized tileclass system)

In D1501#79867, @smiley wrote:

For all the people who have spent countless hours messing with this, that is only partly true. The last point is only true in a subset of map designs. (Jebel Berkal a prime counter-example)

It's true for most maps that aren't Jebel Berkal.

Most importantly, early-returning is entirely pointless when you have done other optimizations. See that tileclass thing lying around which have promising results. Those results could be matched and even faster at times without losing a feature that have interesting use cases.

I don't think so. Even with all the other optimizations this can still represent a significant speedup. Also there were no features lost by this. The behavior is exactly the same, only faster in a lot of common cases.
I mean literally all the function does is say "yes this location meets the requirements" or "no this location doesn't meet the requirements". That's all it ever did, except that it did so more wastefully before since it would keep calculating even after success or failure had already been established.

(But most importantly, I like to see how this patch ends up)

Meh. :P If I ever manage to get back into it.

Update copyrights

Added context, hopefully.

In D1581#72151, @vladislavbelov wrote:

I would ask you add a context to your patch.

In D1780#72137, @Nescio wrote:

“Legionnaire” is common in English when referring to a member of e.g. the French foreign legion, however, “legionary” is the English word used specifically for the Roman soldier:

legionary *noun* (pl. legionaries) a soldier in a Roman legion.
*adjective* of an ancient Roman legion.

It's a proper English word and refers to exactly what we have in game, therefore let's use it.

"legionary" isn't a word that anyone uses. English borrows the french "legionnaire" (breton influence), although the original latin "legionarius" would also be acceptable for a roman unit and might even be preferred in this context.

In D1437#66450, @elexis wrote:

I think the problem is that this GL error is not reported to the user in a way that the average user comprehends.
Or rather the problem, nor the setting change are reported at all (barring the unreadable barely noticeable openGL mainlog error).

I sort of fixed that in my unrelated shadow revision. Sort of. The error is still reported via the GL error text, but I made it more understandable and just had it recursively reduce the size until it allocs properly or fails completely. Also the settings GUI won't update until you close it and open it again even after the resolution has been reduced by the backend code if/when it fails. I don't think there's any way around that due to the way the settings panel works.

I think the real issue here is the lack of a proper "place object" cursor mode. If you select an object to place then you get an object placement cursor, but if you switch to anything else then there's no way to get back the object you were placing except to select some other object first to get the object placement cursor back, then switch to the object you actually wanted. Most of the other cursors have proper modes so if you switch to a mode you get whatever it was you were last using with it, but object placement doesn't have any indicator that that's what you're even doing until you start moving the cursor around and see the object on it.

ok now const should be correct. :|

Fix consts, since pass-by-value doesn't need to be marked const on inputs. >.>

consts.

Reinstated the setter function for cinemapath, but added a small tweak so that it respects mod settings properly.

In D1581#63529, @elexis wrote:

AIManager. The territoryMap variable is indeed used in many places of petra. That's unfortunate. I didn't give up hope on putting it out with early returns, but it doesn't look promising either.

Fix indentation.

Changed it to use territorymanager.xml rather than a js function call.

In D1581#63506, @elexis wrote:

That's BuildTextureRGBA? Besides the two texture filenames there could be a boolean stating whether the minimap renders the terrain outlines.

In D1581#63504, @elexis wrote:

Sadly the petra bot has very many hardcodings unfortunately indeed and we currently have noone knowing how that code works.
But if one can disable TerritoryDecay and Capturing that's a start.

In D1581#63463, @Stan wrote:

Might want to make sure as well that the territory does not have any influence, so we can have the classical mode @wowgetoffyourcellphone talked about. Because switching territory visibility off is nice, but it might confuse people. Also it will have to be made an option, and that option shouldn't be available for rated games.

Thanks for the patch.

Derp. Now it should build.

I replaced the tileclass member counting function used by constraints with a function that returns either true or false, using early exit for success/failure depending on the type of query. The early exit should moderately reduce the cost of constraints checking, which is probably the largest single cost for generating maps.

In D1555#62868, @elexis wrote:

Forgot to repeat the downside that one client with the patch and one client without the patch starting the game do result in an instant OOS. (If singleplayers experience any difference at all after this patch, it's one bugs less when starting the game and no difference on savegame load.)

Well that's a fair observation but more or less irrelevant since different game versions tend to be incompatible anyway. It just means that the update will be mandatory, which for fixing OOS errors and timeouts was pretty much expected.

Added support for height and slope constraints to getConstraints().

I extended the removal of deprecated functions to createStragglerTrees.

I've also had this problem, esp with larger maps. Pretty much anything more complicated than mainland will cause the game to be unjoinable and unrejoinable.

Couldn't this be applied equally the other direction? That is, if a unit is unpacked and packing up, and then given an order to attack something within range, to automatically cancel packing?

Third time's the charm? :|

More lint...

More lint.

Alright I condensed the mountain range builder into a single function and moved it into gaia_terrain.

In D1501#61476, @elexis wrote:

I added a nearClasses function for generating that particular type of constraint, which did not previously have a factory.

As mentioned in D1497, I purposefully not introduced that function because these helper functions can be be deleted if the constructors of the Constraints support receiving multiple arguments.
This way the library can become smaller and easier to comprehend for beginners without losing features.

Lint.

Some notes:

• I don't think near and far plane values should be included. Those aren't settings that most people care about and they can break things.
• Most of the camera options are broken in the engine. They do not work and need to be fixed or perhaps just implemented before these options will do anything.
• You'll need scripting hooks to the camera control settings engine side in order for changes to options to have any effect without restarting.
• Tilt up/down using the (control+) scroll wheel would be nice. Currently it's not implemented and due to the peculiarities of scroll wheel controls it doesn't work if you try to set regular tilt up/down to use the scroll wheel.

In D1497#61397, @niektb wrote:

In D1497#61366, @aeonios wrote:

Eh, that's a limitation of the map generator interface. Ultimately I decided to split it back up into summer and winter variants rather than trying to get the snow and grass to mix in any sort of coherent way.

Nah, that's not what I mean. I know 0 A.D. blends textures really poorly and that the Random Map painter is even worse at painting textures. (I've written Random Maps myself too :) )
I was trying to describe the marked area in my image :P

Moved back to summer/winter variants and improved the texture variation and the way decorations are placed.

It seems most maps are just different combinations of randomized resources lakes and hills and only differ at textures and models.
What I like to see for 0 A.D. are truly unique maps that are entirely different than every other map. Ambush in Alpha 19, Red Sea, Mediterranean in Alpha 20, Danubius and Extinct Volcano in A21, Jebel Barkal, Elephantine, Lower Nubia, Hellas in Alpha 22 for instance.
(There are considerably many players who just want mainland forever though)

Most of the maps aren't very random at all. They use a very strict construction formula that basically only differs in the number of players placed on the map. A lot of the maps you mention here have terrible gameplay as well. Mediterranean is bad in every imaginable way. Extinct Volcano is hideously ugly and the texture creates a false impression of cliffs and things where there are none. Aside from the city, Jebel Barkal is an extremely boring map, and also not applicable to ranked games. Elephantine is basically always the same map, nothing random about it. Same with lower nubia, with the additional problem that it's horribly imbalanced to the point of being unplayable for whoever gets stuck in the north. Hellas is kind of interesting but it often generates terrain that's extremely frustrating to play on.

In D1497#61364, @niektb wrote:

One thing that always bugged me was that Alpine Valleys only used one single texture for the mountain (yet never came around to actually change that), any change you could change that for this RMS? :) (unless everybody else disagrees with me ofc :))

I hadn't really thought about it, but you're right the mountain texture is pretty monotonous. I'll look into that next.

Btw, I see a little texture glitch (?) on the very first screenshot, left-side little to the bottom. The transition from snow to grass features two perfect straight lines and a perfect straight angle connects them (if you understand what I mean)

Eh, that's a limitation of the map generator interface. Ultimately I decided to split it back up into summer and winter variants rather than trying to get the snow and grass to mix in any sort of coherent way.

Also, it seems like you use only one texture for everything (so one snow texture, one grass texture etc). Maybe introduce a little more eyecandy there?

Yes I've already done a bunch of work in adding variety to the ground textures. It became more or less a necessity when splitting them into summer and winter.

In D1497#61355, @elexis wrote:

I am a fan of the original map (at least the one from the last three years), so if there are changes, they should be definite improvements and I'm not sure they are.
(It's hard to find out exactly what changed because everything was changed and everything moved.)

You could just try generating maps with it and see what it produces. :P

Minor fixes, reduce redundant painting. Also simplified the mountain range generator to use a terrain painter rather than a layered painter (for which there was no point).

Lint.

Some screenshots:

• Removed all indentation for macros.
• Reverted default.cfg to preferglsl=false
• Reduced blur scaling for PCSS from 1.25 to 1.0

In D1486#61046, @vladislavbelov wrote:

Not all my questions were fixed or answered.

wraitii fixes.

In D1437#61071, @vladislavbelov wrote:

So we only need to switch quality to the lowest, and the problem has gone away.

Increased the PCSS shadow blur rate a bit. At 1.0 light size there was barely any blur at all, and at 1.5 there was too much, so I set it to 1.25 as a compromise.

Fixed some nonsense from svn being dumb.

Fixes for vlad's comments. Shadows now use the proper shadow frustum bounding box information to scale PCF blurs consistently.

Included terrain renderer changes for soft shadows.

fixed hdr.xml -> HDR.xml, rather than just deleting the old files without replacing them.

Closing this for now. It'll be merged with postproc changes in a new revision including all the PCSS work.

Closing this. It's gotten so entangled with shadows that I'm just going to merge the two revisions.

I compiled this and it crashed when I tried to load med cove in atlas. I didn't get anything specific, just an access violation.

This is a bad idea. If the shadow map fails to allocate this will disable the shadows option, preventing the user from changing the shadow quality option which depends on it, thus basically preventing them from fixing the problem and forcing them to be stuck without shadows unless they manually dig into their config file to change the setting.

In D1454#60581, @wraitii wrote:

I think this might need some atlas touchups, and I'd rather backwards-compatibility be created by changing map settings rather than hardcoding it.

In D1454#60564, @ffffffff wrote:

Need to correct my statement. Anti-Aliasing support with opensource drivers (mesa) sometimes has changes or problems in its releases or/and maybe combined with some distro packages (here Ubuntu 16.04) to enable this feature. With updated mesa stack (to the newest) anti-aliasing now works via dri. Just adding this statement.

In D1450#60480, @Stan wrote:

Glad to see you figured out how to make options :P
Did you know you could make revisions dependent on each other ?

I reduced the big blur from 9 taps to 5 taps, which when using linear sampling uses the same number of samples as the 3-tap small blur. This allowed me to simplify the code by reusing the same code for both 3-tap and 5-tap blurs and just changing the offsets and weights. Visually you can't really tell the difference. I also reinstated using all 3 blur textures for bloom, since the smallest blur texture increases the sharpness of the bloom and makes it look a little better. Since that texture is already being sampled by the shader as long as dof is enabled it adds exactly zero overhead one way or the other.

Ok this is getting a major overhaul. I figured out how to implement PCSS for soft shadows and got it working, but that touches a million different files which will cause conflicts with my grand unified postproc shader revision, at least until that gets merged. For the moment I'm going to have to shelve this, but until all of that is sorted out, screenshots!

In rP21786#30465, @temple wrote:

This doesn't really have much to do about packing or rP21630, it's changing the attack-move sub-orders from forced to not forced so units won't chase targets anymore.
In particular, units in defensive stance won't attack any units on the route until they're close enough to their destination. That doesn't seem correct to me, but I guess we'll see how many bug reports we get.

In D1467#60154, @Stan wrote:

Usually what is done is that there is a number of ragdolls set by the engine. The way it could be implemented would be to iterate through all decaying entities and remove the one that have decaying for the longest until you reach the number set.

That'd probably be more expensive than just increasing the sink rate dependent on the number of corpses relative to the preferred max. Doing it that way doesn't require any extra iterations over the corpses and doesn't cause corpses to suddenly disappear.

In D1454#59832, @vladislavbelov wrote:

Expensive is the pretty relative meaning. The blur is expensive too. How much the combining expensive? We need to choose between usability and performance.

The biggest cost, as with most postproc-type rendering, is in memory bandwidth. Both the blur process and the final combine are shared by bloom and dof. That means the blur process only needs to be performed once for both shaders (and blur can indeed be expensive, as in causes a noticeable slowdown if overused) and the combine can read the screen texture once and write it once for both shaders. Also, as I've mentioned, combining them allows the visual effect to be consistent whether applying just one of the effects or both. There's no loss of usability and you only pay for what you use. However if you use both you get a cost discount. DOF could support customization through atlas (ie distance factor, distance scale kind of like fog), but that's not immediately needed.

We use the javascript language for the game logic. It's expensive, but it allows many useful things. Deferred rendering is expensive, but it allows to calculate PSM with high precision, virtual textures, etc. Raytracing is expensive, but it allows nice AO.

True but getting the best visual effect for a given cost is always good.

Right now custom postproc effects are not actually supported by postproc manager, but that's beyond the scope of this revision.

It's not actually true, you can customize effects by editing a map file manually.

Eh? How? AFAIK you can't actually use custom shaders. You can configure effects that are already supported, but you can't set up custom textures or FBOs or manage the rendering process.

My point is to allow to artists/modders to freely edit effects. Why? Because if you will profile the game, you will notice, that postproc or final rendering don't cost a lot, the most expensive thing is object submitting. As you noticed we don't use instanced rendering, so we draw a lot of tries/units per different calls. So until we have the completely different bottleneck, we don't need to do optimizations that break usability too early.

There's nothing here that prevents map makers from customizing things just as well as they can do already. Well, at the moment they can't turn off DOF but it wouldn't be a large step to allow it and to even make it customizable. That's mostly a matter of atlas though and beyond the scope of this revision. If you give atlas the necessary capabilities I can certainly handle the backend support. This won't be live until at least a24 anyway so we've got time. The way postproc is handled with maps isn't really ideal, and only allowing one effect is rather limiting. Due to how bad DOF was before I don't think there are any maps that use DOF intentionally anyway.

But the BIG word doesn't mean something exact. Why not call it as I mention above (actualSize, fullSize, etc)?

"actualSize" and "fullSize" aren't any more meaningful either. One blur is a 3 tap gaussian blur and the other is a 9 tap gaussian blur. Both are gaussian blurs and both are "actualSize", but one is bigger than the other which is why I named it such.

no effects:

Naming/whitespace tweaks.

In D1454#59599, @vladislavbelov wrote:

How Postprocessing should work? An artist/modder has the Atlas or a text editor. He/she adds a list of different PP-effects (i.e. bloom, BW, cartoon) to a map and it works together. Effects are like components. So you don't have to do all things in the one file. And it'd be very good to choose an order of effects.

But if you don't know how to do it or don't want to do yourself, you can wait me. I plan to make changes to the Atlas to allow multiple effects with a different order.

In D1454#59593, @vladislavbelov wrote:

You don't need to be compatible. You just need the same position and the same angle of the camera. You can hardcode it, or just use a simple cinemapath.

That'd be a lot of work. Way more than is justified for taking screenshots.

whitespace

Fixed the bit at line 690 in map reader.

Ok so I got around to dealing with compatibility issues. The way maps interact with postproc is kind of a pain but I made it work as sensibly as I could.

In D1454#59519, @vladislavbelov wrote:

I like this at all, but I have important notes:

• Screenshots should be before/after, not just after. Also they all have the pretty same angle, that's not good for any comparison.

Added spaces to the for blocks, converted '5' into a constant.

This is what the current dof shader looks like:

++i

Removed redundant blurRadius variable.

Fixed indentation and changed the 'numSamples' constant to be used everywhere that it's applicable.

Old shadows: