Changed CPU velocity calculation for EMISSION_SHAPE_DIRECTED_POINTS
to follow the same logic as in the GPU version:
mat2 rotm;
rotm[0] = texelFetch(emission_texture_normal, emission_tex_ofs, 0).xy;
rotm[1] = rotm[0].yx * vec2(1.0, -1.0);
VELOCITY.xy = rotm * VELOCITY.xy;
Now both CPUParticles2D & CPUParticles3D (z disabled) show the same results
as their GPU counterparts and take the initial velocity settings into account.
(cherry picked from commit 1c231cacb3)
The editor wasn't clearing the debugger agent
settings properly after a processing a play
request from an IDE. This caused consequent play
attempts to fail if not launched from the IDE,
as the game would still attempt and fail to
connect to the debugger.
The concrete cause: Forgetting to clear the
`GODOT_MONO_DEBUGGER_AGENT` environment variable.
(cherry picked from commit 6e7da72648)
This is a cherry-pick of
ced77b1e9b
with several 3.2 specific alterations.
There are a lot of build issues coming from
old style projects. At this point fixing every
single one of those would require adding patch
after patch to the project file, which is a
considerable amount work and makes the csproj
even more bloated than it already is.
As such I decided this effort would be better
spent back-porting the Sdk style support that's
already available in 4.0-dev to the 3.2 branch.
This will prevent many issues, but it will also
introduce other benefits, among them:
- While target framework stays as .NET Framework
v4.7.2, it can be changed to .NET Standard 2.0
or greater if desired.
- It makes it much easier to add future patches.
They are added to Godot.NET.Sdk and the only
change required in Godot code is to update the
Sdk version to use.
- Default Godot define constants are also
backported, which fixes IDE issues with the
preprocessor.
There are a few differences in the changes
applied during patching of the csproj compared
to 4.0 with the purpose of preventing breaking
builds:
- 'TargetFramework' stays net472 both for new
projects and when importing old ones. It can
be manually changed to netstandard 2.0+ if
desired though.
The following features are enabled by default for
new projects. Enabling them in imported projects
may result in errors that must be fixed manually:
- 'EnableDefaultCompileItems' is disabled as it
can result in undesired C# source files being
included. Existing include items are kept.
As long as 'EnableDefaultCompileItems' remains
disabled, Godot will continue taking care of
adding and removing C# files to the csproj.
- 'GenerateAssemblyInfo' is disabled as it
guarantees a build error because of conflicts
between the existing 'AssemblyInfo.cs' and the
auto-generated one.
- 'Deterministic' is disabled because it doesn't
like wildcards in the assembly version (1.0.*)
that was in the old 'AssemblyInfo.cs'.
Of importance:
This is a breaking change. A great effort was
put in avoiding build errors after upgrading a
project, but there may still be exceptions.
This also breaks forward compatibility. Projects
opened with Godot 3.2.3 won't work out of the box
with older Godot versions. This was already the
case with changes introduced in 3.2.2.
Albeit C# support in 3.2.x was still labeled as
alpha, we've been trying to treat it as stable
for some time. Still the amount of problems this
change solves justifies it, but no more changes
that break project compatibility are to be
introduced from now on (at least for 3.x).
This upgrade is needed in order to support
reading and editing project files that use Sdks
as well as other new features. A common example
in 3.2 is having to specify a PackageReference
version with a child element rather than the
attribute. This is no longer the case now.
Partial cherry-pick of f3bcd5f8dd
Most of the other changes from that commit were already partially
cherry-picked in 3928fe200f.
Not sure if we should check revision too, but this is good enough for what we want.
This will be needed to load the correct Microsoft.Build when we switch to the nuget version.
Manual cherry-pick of af4acb5b11 (relevant parts)
By default 'add_ios_framework' would not embed a framework to save previous behavior.
New 'add_ios_embedded_framework' would embed framework on export.
Normal mapping previously took no account of rotation or flips in any path except the TEXTURE_RECT (uniform draw) method. This passed flips to the shader in uniforms.
In order to pass flips and rotations to the shader in batching and nvidia workaround, a per vertex attribute is required rather than a uniform. This introduces LIGHT_ANGLE which encodes both the rotation of a quad (vertex) and the horizontal and vertical flip.
In order to optionally store light angles in batching, we switch to using a 'unit' sized array which can be reused for different FVF types, as there is no need for a separate array for each FVF, as it is a waste of memory.
Prevents adding new octants until a limiting number of elements have been added to the current octant. This enables balancing the benefits of brute force against the benefits of spatial partitioning. The limit can be set per octree.
Project settings are added for rendering octree to set the best balance per project depending on number of tests per frame / tick, and the amount of editing of the octree.
Fixes octants being leaked when removing elements.
Optimize octree with cached linear lists
Storing elements in octants using linked lists is efficient for housekeeping but very slow for testing. This optimization stores additional local_vectors with Element pointers and AABBs which are cached and only updated when a dirty flag is set on the octant.
This is selectable with 2 versions of Octree : Octree and Octree_CL, Octree being the old behaviour. At present the cached list version is only used for the visual server octree (rendering) as it has only been demonstrated to be faster there so far.
This uses slightly more memory (probably a few kb in most cases) but can be significantly faster during testing (culling etc).
Co-authored-by: Sergey Minakov <naithar@icloud.com>
In rare circumstances an item would issue multiple transform commands before a (non rect) draw command. The command syncronization would incorrectly start from first transform, instead of the current transform in these circumstances, which could have the result of missing drawing some commands from the end of the batch.
This had been shown in the wild occuring in debug collision polys. It was a benign error (sometimes visual elements would be lost), but did not cause any serious problems.
This PR fixes this synchronization error.
New contributors added to AUTHORS:
@hinlopen, @naithar, @rrcore, @SkyLucilfer, @TwistedTwigleg
Thanks to all contributors and donors for making Godot possible!
---
Also changes to relevant code that parses the DONORS.md to match
the new tiers.
(cherry picked from commit d2d4c1c957)
