Users can add additional VS project configurations with their own
custom settings, but to support this workflow, we can't rely directly
on $(Platform) and $(Configuration), because VS needs those to be
both unique Configuration|Platform combos, and we need to allow for
different combos of Configuration|Platform to point to the same
scons build configuration.
GodotPlatform and GodotConfiguration properties lets us decouple from
the magic VS properties that we don't control, so users can add
however many Platform|Configuration combos they want and still
point to a specific GodotPlatform|GodotConfiguration build config.
Make sure we include any user-specified project settings in our
project definitions, this way users can customize their VS
environment to more closely match what they're building for, and
they better can control debugging and deployment from VS.
Add support for setting VS-only compiler defines, include paths, and
additional linker options, as a hint to VS to use when loading projects
and parsing code. VS would usually know these on non nmake projects,
but for nmake projects we have to tell it about any implicit information
that the compiler has, so it can resolve symbols in the editor.
Using 2.2.7.dev115+g0eb441d6.
Had to add `cancelled` to the ignore list, as it's a Wayland signal which
we're handling in our code, so we don't want codespell to fix that "typo".
Also includes the typo fix from #87927.
Co-authored-by: Divyanshu Shekhar <61140213+divshekhar@users.noreply.github.com>
ShaderMaterial is the "advanced" option, while the "basic" options
should be listed first for easier accessibility (and because they're
generally used more often).
This makes sky and particle materials consistent with
canvas/spatial/fog materials on this aspect.
Custom Visual Studio project generation logic that supports any platform that has a msvs.py
script, so Visual Studio can be used to run scons for any platform, with the right defines per target.
Invoked with `scons vsproj=yes`
To generate build configuration files for all platforms+targets+arch combinations, users should call
```
scons vsproj=yes platform=XXX target=YYY [other build flags]
```
for each combination of platform+target[+arch]. This will generate the relevant vs project files but
skip the build process, so that project files can be quickly generated without waiting for a command line
build. This lets project files be quickly generated even if there are build errors.
All possible combinations of platform+target are created in the solution file by default, but they
won't do anything until each one is set up with a scons vsproj=yes command for the respective platform
in the appropriate command line. This lets users only generate the combinations they need, and VS
won't have to parse settings for other combos.
Only platforms that opt in to vs proj generation by having a msvs.py file in the platform folder are included.
Platforms with a msvs.py file will be added to the solution, but only the current active platform+target+arch
will have a build configuration generated, because we only know what the right defines/includes/flags/etc are
on the active build target currently being processed by scons.
Platforms that don't support an editor target will have a dummy editor target that won't do anything on build,
but will have the files and configuration for the windows editor target.
To generate AND build from the command line, run
```
scons vsproj=yes vsproj_gen_only=no
```
This makes it much faster to get started with Direct3D 12 builds,
as you only need to run `python .\misc\scripts\install_d3d12_sdk_windows.py`
then run `scons d3d12=yes`.
This installs DirectX Shader Compiler, Mesa NIR, WinPixEventRuntime
and DirectX 12 Agility SDK.
- Define a default path that uses the locations from the script.
- Now the default path is in "%LOCALAPPDATA%\Godot\build_deps\"
- Updated CI to use this new python script.
Co-Authored-By: Hugo Locurcio <hugo.locurcio@hugo.pro>
This works even if file logging is disabled in the project settings,
or for the editor/project manager.
`--log-file`'s value can be an absolute path or relative to the project
directory (similar to existing arguments like `--write-movie`).
Adds a new system to automatically reorder commands, perform layout transitions and insert synchronization barriers based on the commands issued to RenderingDevice.
It only introduced a difference in a .glsl file, which I've worked
around by removing an empty line. This keeps formatting consistent
between clang-format 15 and 16.
Also added a change in the 3-to-4 project converter to fix bogus
formatting in clang-format < 17.
This allows Godot to automatically compress meshes to save a lot of bandwidth.
In general, this requires no interaction from the user and should result in
no noticable quality loss.
This scheme is not backwards compatible, so we have provided an upgrade
mechanism, and a mesh versioning mechanism.
Existing meshes can still be used as a result, but users can get a
performance boost by reimporting assets.
The UWP platform port was never ported to the Godot 4.0+ API,
and it's now accumulating bitrot as it doesn't compile, and thus
we no longer propagate platform changes in it.
So we finally remove to acknowledge this state. There's still some
interest in reviving the UWP port eventually, especially as support
for Direct3D 12 will soon be merged, but when that happens it will
be easiest to redo it from scratch.
- Add compatibility methods for `RenderingDevice::shader_create_from_bytecode`
and `CodeEdit::get_text_for_symbol_loopup`.
- Silence errors which now have compatibility methods.
- Acknowledge GraphEdit/GraphNode compat breakage, intended and WIP.
This allows limiting framerate on any project, which is useful to
reduce power usage and latency with certain setups (such as VRR displays).
This is particularly useful in projects that do not expose a setting to change
the FPS limit. While external FPS limiters can be used, they can be cumbersome
to set up and result in increased input lag compared to a built-in FPS limiter.
