The blue accent color is now used, which matches the default editor
accent color.
It doesn't change to match the currently configured accent color
automatically, but doing so would require modifying the CheckButton
class a lot for little benefit.
(cherry picked from commit 114c1a78d9)
Fixes a pre-existing bug that #44433 exposed.
It's pretty hacky, but we use `platform` in `env` both as an optional command
line option (instead it can be autodetected, or passed via the `p` alias, and
on Linux it might be overridden if you pass one of the convenience alias
values), and as the reference value for what platform we're building on.
Thus we override `env_base["platform"]` with the autodetected or validated
platform, but any call to `opts.Update(env_base)` overrides it with the
original command line option... causing e.g. #44448.
The proper fix would be to refactor all this so that we don't reuse
`env["platform"]` for platform detection (it could instead be e.g.
`env.platform` as a member variable which holds the validated value),
but for now I'm tapering over the immediate breakage.
Fixes#44448 and other breakages induced by #44433.
(cherry picked from commit 8f660393fe)
Otherwise we can get situations where platform-specific opts with the same name
can override each other depending on the order at which platforms are parsed,
as was the case with `use_static_cpp` in Linux/Windows.
Fixes#44304.
This also has the added benefit that the `scons --help` output will now only
include the options which are relevant for the selected (or detected) platform.
(cherry picked from commit 0f84d8dc49)
- Brighten gizmos when highlighted to make the difference between a
non-highlighted and a highlighted gizmo more visible.
- Tweak the manipulator gizmo size property hint.
(cherry picked from commit 8522ac7711)
This is needed with newer Mono versions, at least with Mono 6.12+
Depends on the following commit from our build scripts:
godotengine/godot-mono-builds@9d75cff174
(cherry picked from commit b98e8b11e6)
See #36285 which mistakenly added documentation for the whole C++ API, while
some of it is meant to be and stay private as it's not exposed to scripts.
The access modifiers and method prefix were not used properly.
Cleanup code, and rename wrong `group_name` parameters to `method`, as it's a
method name which is being broadcast.
This is a very old class from pre-open source days, chances are that it was
just forgotten and not meant to be kept as is and undocumented.
(cherry picked from commit 79ba70f7ee)
The code we had for PVRTexTool doesn't work as it's not compatible with current
PVRTexTool CLI options, and likely hasn't been for years.
Instead, we have our own vendored pvrtccompressor thirdparty library which all
users have thus de-facto been using. This commit moves the compress code to
`modules/pvr` where it belongs.
There's no proper compress function for PVRTC 2-bit format, that's a bug that
will need to be fixed (currently it's compressed as 4-bit format even if you
use Image::FORMAT_PVRTC2).
Fixes#28669.
(cherry picked from commit 1a31274855)
They didn't show up at all in the rendered PNG, but were pretty annoying when working with Gobot face on Inkscape
(cherry picked from commit 17b9cb2cdf)
Alternative to `_change_notify()` to be called from within C++ classes.
Achieves low-level consistency with scripting, where this method is
exposed for updating the editor (inspector) with new values.
(cherry picked from commit 9aa06c3e65)
Ninepatch code has a check to prevent use of zero sized textures. This didn't deal properly with animated textures, which use a proxy (link to another texture).
This PR uses a generalised method of getting textures, with built in support for proxy textures and protection against infinite loops.
These were only put in for the betas, in order to test hypotheses for stalling on Macs. It seems that most of the problems in the Mac editor have been solved by fixing the excessive redraw_requests.
As a result no one has reported any results from these options, but in future we will be able to refer users to try the beta versions, so there is no need to include them in the stable release. Indeed they are only likely to cause confusion.
The root cause of the issue is that OpenGL ES 2 does not support the `textureCubeLod` function.
There are (optional) extensions to support this, but they don't appear to be exposed with the ES2 renderer (even though the hardware needed to support LOD features are certainly available.)
The existing shim in `drivers/gles2/shaders/cubemap_filter.glsl` just creates a macro:
```
#define textureCubeLod(img, coord, lod) textureCube(img, coord)
```
But the third parameter of `textureCube` is actually a mip bias, not an absolute mip level.
(And it doesn't seem to work regardless.)
In this specific case, the `cubemap_filter` should only sample from the first level of the "source" panorama cubemap.
In lieu of a method to force a lod level of zero, I've chosen to comment out the switchover from a 2D equirectangular panorama to the cubemap version of the same image, therefore always sampling roughness values from the 2D equirectangular panorama.
This may cause additional artifacts or issues across the seam, but at least it prevents the glaringly obvious black areas.
---
This same issue (no fragment texture LOD support) has rather large repercussions elsewhere too; it means materials with larger cubemap density (i.e. planar or distant objects) will be far rougher than expected.
Since GLES 3 appears to properly support fragment `texture*Lod` functions, switching to the GLES 3 backend would solve this problem.
---
Root cause discovered with help from @KaadmY.
