| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
- Rename OpenGL to GLES3 in the source code per community feedback.
- The renderer is still exposed as "OpenGL 3" to the user.
- Hide renderer selection dropdown until OpenGL support is more mature.
- The renderer can still be changed in the Project Settings or using
the `--rendering-driver opengl` command line argument.
- Remove commented out exporter code.
- Remove some OpenGL/DisplayServer-related debugging prints.
|
|
Based on #36572 which added support for Linux
|
|
|
|
We've had many issues with WebM support and specifically the libvpx library
over the years, mostly due to its poor integration in Godot's buildsystem,
but without anyone really interested in improving this state.
With the new GDExtensions in Godot 4.0, we intend to move video decoding to
first-party extensions, and this would likely be done using something like
libvlc to expose more codecs.
Removing the `webm` module means we can remove libsimplewebm, libvpx and
opus, which we were only used for that purpose. Both libvpx and opus were
fairly complex pieces of the buildsystem, so this is a nice cleanup.
This also removes the compile-time dependency on `yasm`.
Fixes lots of compilation or non-working WebM issues which will be linked
in the PR.
|
|
They're the same for all platforms so they don't need to be repeated in all
platform definitions.
|
|
This will allow adding developer checks which will be fully compiled out in
user builds, unlike `DEBUG_ENABLED` which is included in debug tempates and
the editor builds.
This define is not used yet, but we'll soon add code that uses it, and change
some existing `DEBUG_ENABLED` checks to be performed only in dev builds.
Related to godotengine/godot-proposals#3371.
|
|
|
|
path option, use xcframework instead of static framework).
|
|
|
|
|
|
|
|
|
|
Bug introduced in #45679.
Fixes part of #45816.
|
|
This is meant for users making custom builds to match the options used on
optimized, official builds.
This enables, on the platforms which support them:
- `use_static_cpp=yes` (portable binaries for Linux and Windows)
- `use_lto=yes` (link time optimizations - note: requires a lot of RAM!)
- `debug_symbols=no` (no debug symbols, smaller binaries)
Also abort when using MSVC with `production=yes`, as:
- It cannot optimize the GDScript VM like GCC or Clang do, leading to
significant performance drops.
- Its LTO support is unreliable, at least used to trigger crashes last
we tried it extensively.
All options can still be overridden if specified, and the `dev=yes` option
was changed to also support overrides.
|
|
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.
|
|
SCons: Remove unnecessary $LINK overrides
|
|
As of SCons 4.0.1, the default value for $LINK is $SMARTLINK, which itself
is a function that will use $CXX as linker for C++:
https://github.com/SCons/scons/blob/4.0.1/SCons/Tool/link.py#L327-L328
https://github.com/SCons/scons/blob/4.0.1/SCons/Tool/link.py#L54-L76
So we don't need to manually specify the same value as $CXX for $LINK.
|
|
For some reason the `-target` option on the `LINKFLAGS` was causing a weird
issue where osxcross' clang wrapper would attempt using the system `/bin/ld`
instead of the osxcross version (which is Apple's `ld64`).
The error message would be:
```
/bin/ld: unrecognized option '-dynamic'
```
Also removed from `CCFLAGS` for consistency, it seems to work fine with only
`-mmacosx-version-min`.
|
|
`debug_symbols=yes` will now behave like `debug_symbols=full` did
before. The difference in compressed file sizes is not that large,
which means there isn't much point in having two different values.
This helps make the buildsystem easier to understand.
|
|
Removed make_binders and the old style generated binders.
|
|
|
|
|
|
Until https://github.com/psf/black/pull/1328 makes it in a stable release,
we have to use the latest from Git.
Apply new style fixes done by latest black.
|
|
build. Add ARM64 breakpoint inline assembly to "doctest".
|
|
Its last use was removed in Godot 3.0, so it no longer makes sense to define.
Also removed `D3D_DEBUG_INFO` for Windows as it's likely a left over from a
long time ago pre-opensourcing when Godot had some form of Direct3D 9 support?
|
|
Fixes this compilation error:
In file included from thirdparty/vulkan/vk_mem_alloc.cpp:7:
thirdparty/vulkan/vk_mem_alloc.h:3691:18: error: 'shared_mutex' is unavailable: introduced in macOS 10.12
std::shared_mutex m_Mutex;
^
/home/[user]/sources/osxcross/target/bin/../SDK/MacOSX10.14.sdk/usr/include/c++/v1/shared_mutex:178:58: note: 'shared_mutex' has been explicitly marked unavailable here
class _LIBCPP_TYPE_VIS _LIBCPP_AVAILABILITY_SHARED_MUTEX shared_mutex
|
|
|
|
Configured for a max line length of 120 characters.
psf/black is very opinionated and purposely doesn't leave much room for
configuration. The output is mostly OK so that should be fine for us,
but some things worth noting:
- Manually wrapped strings will be reflowed, so by using a line length
of 120 for the sake of preserving readability for our long command
calls, it also means that some manually wrapped strings are back on
the same line and should be manually merged again.
- Code generators using string concatenation extensively look awful,
since black puts each operand on a single line. We need to refactor
these generators to use more pythonic string formatting, for which
many options are available (`%`, `format` or f-strings).
- CI checks and a pre-commit hook will be added to ensure that future
buildsystem changes are well-formatted.
|
|
This reverts commit c924e83a646f8a6d972ccd4d009acc323a6be158.
SCons `FRAMEWORKS` is, according to their latest docs, only supported
"On Mac OS X with gcc". While the "with gcc" part seems bogus, #36795
did introduce a link failure for our osxcross toolchain for compiling
macOS binaries from Linux. SCons probably fails to detect this as a
macOS target and does not use its `FRAMEWORKS` logic properly.
So using `LINKFLAGS` as we used to is the more portable solution.
|
|
Scons release 0.96.91
Fixes the link errors below
clang: error: no such file or directory: 'Carbon'
clang: error: no such file or directory: 'AudioUnit'
clang: error: no such file or directory: 'CoreAudio'
clang: error: no such file or directory: 'CoreMIDI'
clang: error: no such file or directory: 'IOKit'
clang: error: no such file or directory: 'ForceFeedback'
clang: error: no such file or directory: 'CoreVideo'
clang: error: no such file or directory: 'AVFoundation'
clang: error: no such file or directory: 'CoreMedia'
clang: error: no such file or directory: 'Metal'
clang: error: no such file or directory: 'QuartzCore'
Tested on
System Version: macOS 10.15.3 (19D76)
SCons by Steven Knight et al.:
script: v3.1.2.bee7caf9defd6e108fc2998a2520ddb36a967691, 2019-12-17 02:07:09, by bdeegan on octodog
engine: v3.1.2.bee7caf9defd6e108fc2998a2520ddb36a967691, 2019-12-17 02:07:09, by bdeegan on octodog
engine path: ['/usr/local/Cellar/scons/3.1.2_1/libexec/scons-local/SCons']
Xcode 11.3.1
Build version 11C504
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin19.3.0
Closes #36720
|
|
As per #36436, we now need C++17's guaranteed copy elision feature to
solve ambiguities in Variant.
Core developers discussed the idea to move from C++14 to C++17 as our
minimum required C++ standard, and all agreed. Note that this doesn't
mean that Godot is going to be written in "modern C++", but we'll use
modern features where they make sense to simplify our "C with classes"
codebase. Apart from new code written recently, most of the codebase
still has to be ported to use newer features where relevant.
Proper support for C++17 means that we need recent compiler versions:
- GCC 7+
- Clang 6+
- VS 2017 15.7+
Additionally, C++17's `std::shared_mutex` (conditionally used by
`vk_mem_alloc.h` when C++17 support is enabled) is only available in
macOS 10.12+, so we increase our minimum supported version.
|
|
- Renamed option to `builtin_vulkan`, since that's the name of the
library and if we were to add new components, we'd likely use that
same option.
- Merge `vulkan_loader/SCsub` in `vulkan/SCsub`.
- Accordingly, don't use built-in Vulkan headers when not building
against the built-in loader library.
- Drop Vulkan registry which we don't appear to need currently.
- Style and permission fixes.
|
|
|
|
Initial Vulkan support for Windows.
Initial Vulkan support for macOS.
|
|
|
|
for macOS CI.
|
|
It's the recommended way to set those, and is more portable
(automatically prepends -D for GCC/Clang and /D for MSVC).
We still use CPPFLAGS for some pre-processor flags which are not
defines.
|
|
This is a new singleton where camera sources such as webcams or cameras on a mobile phone can register themselves with the Server.
Other parts of Godot can interact with this to obtain images from the camera as textures.
This work includes additions to the Visual Server to use this functionality to present the camera image in the background. This is specifically targetted at AR applications.
|
|
Include paths are processed from left to right, so we use Prepend to
ensure that paths to bundled thirdparty files will have precedence over
system paths (e.g. `/usr/include` should have lowest priority).
|
|
Many contributors (me included) did not fully understand what CCFLAGS,
CXXFLAGS and CPPFLAGS refer to exactly, and were thus not using them
in the way they are intended to be.
As per the SCons manual: https://www.scons.org/doc/HTML/scons-user/apa.html
- CCFLAGS: General options that are passed to the C and C++ compilers.
- CFLAGS: General options that are passed to the C compiler (C only;
not C++).
- CXXFLAGS: General options that are passed to the C++ compiler. By
default, this includes the value of $CCFLAGS, so that setting
$CCFLAGS affects both C and C++ compilation.
- CPPFLAGS: User-specified C preprocessor options. These will be
included in any command that uses the C preprocessor, including not
just compilation of C and C++ source files [...], but also [...]
Fortran [...] and [...] assembly language source file[s].
TL;DR: Compiler options go to CCFLAGS, unless they must be restricted
to either C (CFLAGS) or C++ (CXXFLAGS). Preprocessor defines go to
CPPFLAGS.
|
|
|
|
Godot supports many different compilers and for production releases we
have to support 3 currently: GCC8, Clang6, and MSVC2017. These compilers
all do slightly different things with -ffast-math and it is causing
issues now. See #24841, #24540, #10758, #10070. And probably other
complaints about physics differences between release and release_debug
builds.
I've done some performance comparisons on Linux x86_64. All tests are
ran 20 times.
Bunnymark: (higher is better)
(bunnies) min max stdev average
fast-math 7332 7597 71 7432
this pr 7379 7779 108 7621 (102%)
FPBench (gdscript port http://fpbench.org/) (lower is better)
(ms)
fast-math 15441 16127 192 15764
this pr 15671 16855 326 16001 (99%)
Float_add (adding floats in a tight loop) (lower is better)
(sec)
fast-math 5.49 5.78 0.07 5.65
this pr 5.65 5.90 0.06 5.76 (98%)
Float_div (dividing floats in a tight loop) (lower is better)
(sec)
fast-math 11.70 12.36 0.18 11.99
this pr 11.92 12.32 0.12 12.12 (99%)
Float_mul (multiplying floats in a tight loop) (lower is better)
(sec)
fast-math 11.72 12.17 0.12 11.93
this pr 12.01 12.62 0.17 12.26 (97%)
I have also looked at FPS numbers for tps-demo, 3d platformer, 2d
platformer, and sponza and could not find any measurable difference.
I believe that given the issues and oft-reported (physics) glitches on
release builds I believe that the couple of percent of tight-loop
floating point performance regression is well worth it.
This fixes #24540 and fixes #24841
|
|
Improve the test logic to only assume that we're building for macOS
if OSXCROSS_ROOT is defined *and* we requested p=osx.
Supersedes #24480.
|
|
Fix regular macOS build by passing -isysroot to compiler so correct system headers are found
|
|
|
|
Previously the compiler would use system headers located at
/System/Library/Frameworks, which could result in compilation failures
due to the headers not always being up-to-date in regards to the
latest installed macOS SDK headers that come with Xcode.
Fix the issue by passing the SDK path via the -isysroot option to the
compiler and linker invocations.
If no custom SDK path is given, the build system queries the SDK path
via xcrun --show-sdk-path, which returns something similar to
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/
/Developer/SDKs/MacOSX.sdk/
Querying via xcrun is now also done for iphone (and simulator)
platforms as well.
Here is an example of a compilation failure message due to outdated
headers:
platform/osx/os_osx.mm:1421:41: error: use of undeclared identifier 'NSAppKitVersionNumber10_12'; did you mean 'NSAppKitVersionNumber'?
if (floor(NSAppKitVersionNumber) >= NSAppKitVersionNumber10_12) {
^~~~~~~~~~~~~~~~~~~~~~~~~~
NSAppKitVersionNumber
/System/Library/Frameworks/AppKit.framework/Headers/NSApplication.h:26:28: note: 'NSAppKitVersionNumber' declared here
|
|
|