It was initially implemented in #5871 for Godot 3.0, but never really
completed or thoroughly tested for most platforms. It then stayed in
limbo and nobody seems really keen to finish it, so it's better to
remove it in 4.0, and re-add eventually (possibly with a different API)
if there's demand and an implementation confirmed working on all
platforms.
Closes#8770.
Due to the port to Vulkan and complete redesign of the rendering backend,
the `drivers/gles3` code is no longer usable in this state and is not
planned to be ported to the new architecture.
The GLES2 backend is kept (while still disabled and non-working) as it
will eventually be ported to serve as the low-end renderer for Godot 4.0.
Some GLES3 features might be selectively ported to the updated GLES2
backend if there's a need for them, and extensions we can use for that.
So long, OpenGL driver bugs!
Happy new year to the wonderful Godot community!
We're starting a new decade with a well-established, non-profit, free
and open source game engine, and tons of further improvements in the
pipeline from hundreds of contributors.
Godot will keep getting better, and we're looking forward to all the
games that the community will keep developing and releasing with it.
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.
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.
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
Contrarily to what #23434 assumed, this is not a memory leak,
the VisualServerRaster instance is passed as a parameter to
VisualServerWrapMT's constructor.
Fixes#23437.
Fixes the following Clang 7 warnings:
```
editor/editor_help.h:123:7: warning: 'EditorHelpIndex::popup' hides overloaded virtual function [-Woverloaded-virtual]
editor/editor_help.h:95:7: warning: 'EditorHelpSearch::popup' hides overloaded virtual function [-Woverloaded-virtual]
editor/editor_help.h:96:7: warning: 'EditorHelpSearch::popup' hides overloaded virtual function [-Woverloaded-virtual]
editor/plugins/curve_editor_plugin.h:141:15: warning: 'CurvePreviewGenerator::generate' hides overloaded virtual function [-Woverloaded-virtual]
editor/plugins/script_editor_plugin.h:70:7: warning: 'ScriptEditorQuickOpen::popup' hides overloaded virtual function [-Woverloaded-virtual]
editor/quick_open.h:69:7: warning: 'EditorQuickOpen::popup' hides overloaded virtual function [-Woverloaded-virtual]
main/tests/test_io.cpp:53:15: warning: 'TestIO::TestMainLoop::input_event' hides overloaded virtual function [-Woverloaded-virtual]
servers/audio/effects/audio_effect_record.h:69:15: warning: 'AudioEffectRecordInstance::process_silence' hides overloaded virtual function [-Woverloaded-virtual]
core/os/memory.h:119:2: warning: destructor called on non-final 'ContextGL_X11' that has virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor]
core/os/memory.h:119:2: warning: destructor called on non-final 'EditorScriptCodeCompletionCache' that has virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor]
core/os/memory.h:119:2: warning: destructor called on non-final 'Engine' that has virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor]
core/os/memory.h:119:2: warning: destructor called on non-final 'PhysicalBone::JointData' that has virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor]
core/os/memory.h:119:2: warning: destructor called on non-final 'VisualServerScene' that has virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor]
core/os/memory.h:119:2: warning: destructor called on non-final 'VisualServerViewport' that has virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor]
```
Also finally move freetype to its own env and disable warnings for it.
Still needs some work to fix the awkward situation of the freetype and
svg modules used in scene/ and editor/ respectively.
This allows more consistency in the manner we include core headers,
where previously there would be a mix of absolute, relative and
include path-dependent includes.
-Project/Editor settings now show tooltips properly
-Settings thar require restart now will show a restart warning
-Video driver is now visible all the time, can be changed easily
-Added function to request current video driver
Using `misc/scripts/fix_headers.py` on all Godot files.
Some missing header guards were added, and the header inclusion order
was fixed in the Bullet module.
Setting the vsync in the main thread, after the rendering thread starts
and takes the OpenGL context fails, so we need to do that before.
Also, for some reason, the main thread cannot make current the context
anymore.
Fixes#13447
Spec version 0.7 from https://standards.freedesktop.org/basedir-spec/basedir-spec-0.7.html
(latest as of this commit).
Three virtual methods are added to OS for the various XDG paths we will use:
- OS::get_data_path gives XDG_DATA_HOME, or if missing:
~/.local/share on X11, ~/Library/Application Support/ on macOS and %APPDATA% on Windows
- OS::get_config_path gives XDG_CONFIG_HOME, or if missing:
~/.config on X11, ~/Library/Application Support/ on macOS and %APPDATA% on Windows
- OS::get_cache_path gives XDG_CACHE_HOME, or if missing:
~/.cache on X11, ~/Library/Caches on macOS and %APPDATA% on Windows
So for Windows there are no changes, for Linux we follow the full split spec
and for macOS stuff will move from ~/.godot to ~/Library/Application Support/Godot.
Support for system-wide installation of templates on Unix was removed for now,
as it's a bit hackish and I don't think anyone uses it.
user:// will still be OS::get_data_path() + "/godot/app_userdata/$name" by
default, but when using the application/config/use_shared_user_dir option
it will now use XDG_DATA_HOME/$name, e.g. ~/.local/share/MyGame.
For now everything still goes in EditorSettings::get_settings_dir(), but
this will be changed in a later commit to make use of the new splitting
where relevant.
Part of #3513.
There are still some left in the Android Java code, even stuff to swap between
GLES1 and GLES2 support from early Godot days... would be good to see some cleanup
there too one day.
The "graphics/api" option for Android exports is removed, as only GLES 3.0 is supported.
It can be readded when GLES 2.0 support comes back. Fixes#13004.
Rename user facing methods and variables as well as the corresponding
C++ methods according to the folloming changes:
* pos -> position
* rot -> rotation
* loc -> location
C++ variables are left as is.
Now that we have a built-in stacktrace on a segfault it would be useful
to have debug information on debug_release builds so that bugreports can
include this information. Without this debug info we will still get
function names in the backtrace but not file location.
This commit will by default build all targets with minimal debug info
and then strip the information into separate files. On MacOS this is a
.dSYM file, on Linux/MingW this is a .debug file. MacOSX will
automatically load a dSYM file if it exists in its debugger. On
Linux/MingW we create a 'gnu debuglink' meaning that gdb and friends
will automatically find the debug symbols if they exist.
Existing workflow for developers does not change at all, except that we
now create two instead of one build artifact by default.
This commit also adds a 'debug_symbols' option to X11, MacOS, and MingW
targets. The default is 'yes' which corresponds to -g1. The alternatives
are 'no' (don't generate debug infos at all) or 'full' which runs with
-g2. A target=debug build will now build with -g3.
Rémi Verschelde
bruvzg
Fabio Alessandrelli
Ibrahn Sahir
BastiaanOlij
hbina085
Guilherme Felipe
Sebastian Hartte
Juan Linietsky
Hein-Pieter van Braam
George Marques
Aaron Franke
Adrien Destugues
Juan Linietsky
Hugo Locurcio
Duy-Nguyen TA
Emmanuel Leblond
Stefano Bonicatti
Rhody Lugo
AndreaCatania
Elliott Sales de Andrade
letheed