The basic point is as in 2.1 (appending the PCK into the executable), but this implementation also patches a dedicated section in the ELF/PE executable so that it matches the appended data perfectly.
The usage of integer types is simplified in existing code; namely, using plain `int` for small quantities.
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.
The rationale for keeping those shared by default is that they're typical
dependencies found on any Linux system, and it saves compilation time and
binary size to link their dynamically.
But since official builds default to all-builtin, and Debian/Ubuntu still
don't have libpng16 (which we now require) readily available on all their
supported releases, it's simpler to bundle all the things.
This does not change the fact that those dependencies *can* be unbundled
on Linux, it's only the default option changing.
Wrapped libpng usage in a pair of functions under PNGDriverCommon,
which convert between Godot Image and png data.
Switched to libpng 1.6 simplified API for ease of maintenance.
Implemented ImageLoaderPNG and ResourceSaverPNG in terms of
PNGDriverCommon functions.
Travis, switched to builtin libpng (thus builtin freetype and zlib also)
so we can build on Xenial.
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.
This updates our local copy to commit 5ec8339b6fc491e3f09a34a4516e82787f053fcc.
We need a recent master commit for some new features that we use in Godot
(see #25543 and #28909).
To avoid warnings generated by Bullet headers included in our own module,
we include those headers with -isystem on GCC and Clang.
Fixes#29503.
In x11, windows and osx crash handlers, check project settings exists
before looking up the crash handler message setting.
Avoids crashing the crash handler when handling a crash outside project
settings lifetime. Instead omitting the configurable message and
continuing with trace dump.
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).
This is the same as #23542 (Fix binaries incorrectly detected as shared
libraries on some linux distros) but for Clang. It should be fine with
Clang 4 or higher.
This adds ThinLTO support when using Clang and the LLD Linker, it's
turned off by
default.
For now only support for Linux added as ThinLTO support on other
platforms may still be buggy.
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.
Added constructor and assignment operator for CharString
from const char* to simplify memory management when working with
utf8/ascii strings for APIs taking char*.
Reworked OS_X11::set_context to use CharString and avoid some manual
memory management.
GLES2 is not designed to be a drop-in replacement for the GLES3 backend,
so the fallback mode has to be used knowingly. It *can* make sense for
simple projects which make sure to handle the differences between both
rendering backends, but most users should stick to one supported backend.
By making it opt-in, we can now use this parameter to define whether to
export ETC textures to Android and iOS when using GLES3 + Fallback.
When using GLES3 without Fallback on Android, set the proper min GLES
version in the AndroidManifest.
Also made the option boolean and renamed it for clarity and to avoid
conflict with the previous String option (which would always evaluate as
"true" otherwise).
Fixes#26569.
It seems that bumblebee doesn't like us creating multiple GL contexts
to avoid this we now detect whether we're running with this software
and don't do anything.
Also drop some unused files.
Renamed:
- `platform/iphone/sem_iphone.h` -> `semaphore_iphone.h`
(same for `osx`)
- `platform/uwp/gl_context_egl.h` -> `context_egl_uwp.h`
- in `platform/windows`: `context_gl_win.h`, `crash_handler_win.h`,
`godot_win.cpp`, `joypad.h` and `key_mapping_win.h` all renamed to
use `windows`. Some classes renamed accordingly too.
- `EditorExportAndroid` and `EditorExportUWP` renamed to
`EditorExportPlatformAndroid` and `EditorExportPlatformUWP`
- `power_android` and `power_osx` renamed to `PowerAndroid` and
`PowerOSX`
- `OSUWP` renamed to `OS_UWP`
Dropped:
- `platform/windows/ctxgl_procaddr.h`
This allows most demos to run without any ubsan or asan errors. There
are still some things in thirdpart/ and some things in AudioServer that
needs a look but this fixes a lot of issues. This should help debug less
obvious issues, hopefully.
This fixes#25217 and fixes#25218
We fork off twice once with and once without DIR_PRIME=1 set. We
then use the vendor string to determine what GPU to use.
We prefer (in order)
1) AMDGPU/AMDGPU-PRO/NVidia non-free driver
2) Intel driver
3) Nouveau
4) Software rendering
If a driver can't be detected it will default to DRI_PRIME=0
Make the sanitizer names more explicit (use_ubsan, use_asan, use_lsan).
Comment has been adjusted to include GCC as supported compiler for these
and exclude -fno-omit-frame-pointer option (should not cause any
problems).
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
The current system for capturing the mouse and generating motion events on X11
has issues with inaccurate and lopsided input. This is because both
XQueryPointer and XWarpPointer work in terms of integer coordinates when the
underlying X11 input driver may be tracking the mouse using subpixel
coordinates. When warping the pointer, the fractional part of the pointer
position is discarded.
To work around this issue, the fix uses raw motion events from XInput 2. These
events report relative motion and are not affected by pointer warping.
Additionally, this means Godot is able to detect motion at a higher resolution
under X11. Because this is raw mouse input, it is not affected by the user's
pointer speed and acceleration settings. This is the same system as SDL2 uses
for its relative motion.
Multitouch input on X requires XInput 2.2. Raw motion events require
XInput 2.0. Since 2.0 is old enough, this is now the minimum requirement to
use Godot on X.
