This one implements "soft edges" of the particles, similar to how all other engines (Unity, UE4, Godot) do that.

This time around it's only for maintenance. I have no game to test it on develop, but should be easy to integrate it in the future.

No soft edges, status quo, visible clipping areas

Softened edges (5.0 elmo, hardcoded), no visible clipping areas

--- 411068f, replaced by c0cd385

~~increase fighter/bomber aircraft maneuverability parameter randomness to 6% from 2% to spread them out a bit more when moving and turning~~

• add airManeuverabilitySpread unitDef : fighter/bomber aircraft maneuverability parameter randomness (previously hardcoded to 0.02, which is the new default)

--- 1196388

• fix fighter/bomber aircraft shaking: When calculating intensities for rudder and aileron make them a function of the deviation from target if difference is below a threshold (value = k*deviation) instead of using +1/-1
• replaced some duplicated code in GetRudderDeflection and GetAileronDeflection (behaviour when attacking or otherwise is mostly the same) for a single block
• on GetRudderDeflection, when target is behind and already turning sharply in one direction, keep it instead of trying to pick a random one

--- ad3b7d8

• added attackOverflyDistance unitDef : controls how far fighter/bomber aircraft move after overflying target. Default value of 0 is converted internally to max(turnRadius, maxWeaponRange). Only applies if attacking and against targets moving at less than 25% of the aircraft's speed.

note: previous behaviors after overflying target before turning were flying a distance function of the turnRadius (which would return 1000 for aircraft flying at any reasonable speed - too much), waiting 3 seconds after the last shot fired, and pretending a nearby goal was in the opposite side of the plane to make it turn in the opposite direction. It was meant to prevent aircraft from flying in tight circles around targets but didn't always work (ex: spawn 40 zk "fighter" and order them to attack ground, sometimes a few get stuck in tight circle and end up firing less than they could). It also calculated aileron and rudder intensity but then multiplied them by 0 to force flying straight, which seems wasteful.

--- 322d515

• randomize fighter/bomber turn direction after overflying target if it is behind in (almost) the same direction (after applying rudder in a direction, it's kept)

Opening a discussion on Spring.OpenURL, this is related to https://github.com/Spring-Chobby/Chobby/issues/89

The use cases for this are mostly for the ingame lobby, with some examples:

• Opening a news/replays/forum, etc. link, that directs the user to the community.
• Clicking on a URL in text (this obviously could also be used for currently available ingame play).

Technically, this also makes it possible to open OS related URLs, such as directories or files, which isn't necessarily a bad thing imo.

So, thoughts? Any reasons against this, or should it be done differently?

• Added support for Lua tesselation shaders:
  • New shaders TES & TCS
  • New function SetTesselationShaderParameter() to manipulate glPatchParameter*()
  • Renamed SetShaderParameter to SetGeometryShaderParameter to avoid confusion between Tesselation shaders and Geometry shader
  • New drawing primitive GL.PATCHES
  • TODO. LuaShaderContainer seems to duplicate LuaShaders code, so TES & TCS should go there too.

I've tested TES & TCS and they work with the following definitions in the tesselation shaders: #version 150 compatibility #extension GL_ARB_tessellation_shader : enable

• Also added support for subroutines. They are useful so different draw passes/techniques could be specified as subroutine uniforms. Currently one has to have several slightly different instances of the the shader to do so.
  • This code has not been tested yet.

I have been investigating the performance issues raised in https://springrts.com/mantis/view.php?id=6362 and https://springrts.com/mantis/view.php?id=6340.

Through building various versions and benchmarking them I have concluded that the threading in ROAM has little benefit. This benchmark shows that ROAM became slower after https://github.com/spring/spring/commit/4bc8b64704f4036638b10a91e2dd46cb836323b0 due to the additional overhead of the dummies, not because threading was removed. The benchmark involves moving the camera rapidly around a unitless map.

This PR adds an additional meshdrawer based on the parent of https://github.com/spring/spring/commit/4bc8b64704f4036638b10a91e2dd46cb836323b0. The access violation identified by Krogoth is resolved by removing the concurrent patch updates. Doing so appears to have no impact on performance. The change here is compatible with future work on the threaded ROAM, since the threaded ROAM is unaffected, and furthermore may be used as a comparison. The unthreaded ROAM should allow games to use the latest engine versions until kloot, or anyone else, has more time to work on terrain rendering.

Here is a benchmark of the PR compared to a few other versions. It is not ideal because it mixes buildbot and locally build engines. This is what the benchmark looks like: https://www.youtube.com/watch?v=2tpk9b6ITFI I previously thought the performance issue with 1463 had been fixed, however that benchmark did not have any camera movement. The small amount of camera movement in the updated benchmark reveals the issue with 1463.

Here is a video comparing the meshdrawers: https://www.youtube.com/watch?v=wZH-g1RiDTY

thoughts about this?

this would make pr-downloader mandatory, atm its optional. is this ok or should it still be optional?

the code still needs some improvements, but the api / file structure should stay the same.

Helper function, gl.GetMapShaderUniform, to get the required uniforms for Spring.SetMapShader set shaders. Also more options have been added to gl.GetMapRendering, to can conveniently set the flags for the map shaders.

An example here.

Obviously related with that.

Possible calls currently are:

• (unitID, weaponNum, targetID)
• (unitID, weaponNum, sourceX, sourceY, sourceZ, targetX, targetY, targetZ)
• (unitID, weaponNum, nil, nil, nil, targetX, targetY, targetZ) required to specify target by XYZ but default source to aimpos

This has problems:

• (unitID, weaponNum, targetID, sourceX, sourceY, sourceZ) is missing: using source by XYZ disallows target by ID, has to be XYZ as well
• (unitID, weaponNum, x, y, z) specifies source and defaults target to (0,0,0) - hardly intuitive and breaks backwards compatibility
• partial triplets such as (unitID, weaponNum, x, y) are accepted - prone to accidents

The PR puts target before source in all cases, allows to append source regardless of whether target is by ID or XYZ, and requires full triplets. Valid calls are now:

• (unitID, weaponNum, targetID)
• (unitID, weaponNum, targetID, sourceX, sourceY, sourceZ)
• (unitID, weaponNum, targetX, targetY, targetZ)
• (unitID, weaponNum, targetX, targetY, targetZ, sourceX, sourceY, sourceZ)

I added utf-8 support to font functions. Now font loads only requred glyphs and add it on a special texture, so lots of function on CglFont are not constant anymore. Also, I moved font classes to rts/Rendering/Fonts, so I changed includes in many files.

ATTN: Possible fix. Didn't properly test it. Also don't know if reference to object replaced by SetObjectArrayElement should be somehow deleted manually.

This commit adds "key mode" functionality to spring 95.

A key mode is a keyboard state that is temporarily activated when you press a key. Once it is active, other key bindings become temporarily available. This allows you to create sequences (e.g. usually of just 2 or 3 keys) which have a unique meaning, and it greatly expands the number of keyboard controls that can be bound to commands.

Example

Using key modes you can have hotkey sequences such as:

ctrl+e,ctrl+e -> select all aircraft ctrl+e,ctrl+r -> select all builders ctrl+e,ctrl+t -> select all buildings ctrl+e,ctrl+a -> select everything

To make this work, edit uikeys.txt with the text:

unbind ctrl+e bind ctrl+e @selmode bind @selmode+ctrl+e select AllMap+_Aircraft+_ClearSelection_SelectAll+ bind @selmode+ctrl+r select AllMap+_Builder+_ClearSelection_SelectAll+ bind @selmode+ctrl+t select AllMap+_Building+_ClearSelection_SelectAll+ bind @selmode+ctrl+a select AllMap++_ClearSelection_SelectAll+

Explanation

In the second line, we bind ctrl+e to a mode called "selmode". This text is arbitrary -- you can call the mode anything you like as long as it is prefixed by the symbol '@'.

In the subsequent lines, we can treat "@selmode" as a modifier just like shift, alt, or ctrl. In these lines, the key sequence that follows is only active when "selmode" is activated. The requirement is that the mode modifier "@selmode" has to come at the start of the key sequence.

This is the Wrong Way: bind ctrl+@selmode+a select AllMap++_ClearSelection_SelectAll+ ..this will not work.

You should not try to bind the same key to multiple actions if one of the actions is a key mode activation. For example, the following is allowed in uikeys.txt, but will not work:

bind ctrl+e say I want this action to occur bind ctrl+e @selmode

Here, the key mode activation will be "hidden" by the first binding. They will not "cycle" as you may be used to seeing with most mods. _A key mode must be the only action bound to a key or key sequence._

However, you can chain together multiple modes to create 3-step, 4-step, or longer length sequences. For example,

bind ctrl+e @modestep1 bind @modestep1+ctrl+e @modestep2 bind @modestep2+ctrl+s say Hello!

This defines a sequence ctrl+e,ctrl+e,ctrl+s -> say "Hello!"

The possibilities are endless! Note that the suffix sequence ctrl+e,ctrl+s might still do nothing by itself.

Configuration setting in springsettings.cfg

Finally, you can control how long a keyboard mode lasts before the default keybindings are reset. Any key mode that is activated will be deactivated and the default keybindings restored after this delay. This means that if you hit the first key and want to abort, you can simply wait out the delay and the default bindings will be restored. The configuration setting is KeyModeResetTime and is measured in milliseconds. The default value is 400 -- this has been found to be "comfortable". If you are a very twitchy player and can hit key combinations fast, you may like to try 200-300 or so. Remember that you need to hit the second (and subsequent) keys in the combination before the reset time expires or those keys will get sent to the default binding rather than the named key mode binding. There is also a configuration setting called KeyModeSustain. If this is set to true, the current key mode will be sustained after a key that uses it has been pushed. This lets you re-use the same mode for multiple subsequent keystrokes if those subsequent keys share the same mode. Setting this value to false will mean the that default key bindings are re-activated immediately after you use a key that is bound into a particular mode.

Enjoy, -MajBoredom

• fixed unbind so that it will accept only one parameter, the key sequence
• unchanged a lexical modification that occurred in the last commit
• added a new boolean configuration parameter KeyModeSustain

This PR adds and exposes a multiplier to the sphere of repulsive force between units. This is part of my attempt to fix pushResistant and give Spring the parameters required to make more starcraft-style units. A multiplier of around 1.3 does not appear to break pathfinding and makes units less clumped. Simply increasing their footprint is a problem with pushResistant, since it blocks and area based on footprint size.

If adding an extra float to SolidObject is somehow terrible for performance then I'd consider adding it to movedefs instead.