fixed and simplified gl_manager_windows
swap buffers now called for all windows
fixed missing pixel format setting in additional windows
this makes them work in OpenGL contexts
changed verbose error printing to write once
this error message happens very frequently while opengl3 is not finished
removed dead code no longer needed after changes
fixed comments that were misinformation
window messages during window creation now handled
these were previously discarded
messages now tunnel the required context
changed failure to create opengl3 window on windows to be more fatal
marked a problem with pen code
conditional compilation of vulkan and opengl3 on windows fixed
windows debug builds now show messages on debug console also
rendering driver selection box now shows only compiled drivers
marked some problematic code
thanks to akien-mga for patiently rewriting my style mistakes
Always build with the GUI subsystem.
Redirect stdout and stderr output to the parent process console.
Use CreateProcessW for blocking `execute` calls with piped stdout and stderr (prevent console windows for popping up when used with the GUI subsystem build, and have more consistent behavior with `create_process`).
Add `open_console` argument to the `execute` and `create_process` to open a new console window.
Remove `interface/editor/hide_console_window` editor setting.
Remove `Toggle System Console` menu option.
Remove `set_console_visible` and `is_console_visible` functions.
Building `target=release` and `target=release_debug` builds with MinGW-GCC
errors when linking with LTO.
Since it's only needed for `target=debug` builds anyway (bigger objects), which
we don't build with LTO, this works around the issue.
Equivalent `-Wa,-mbig-obj` for GCC/Clang.
This started being needed to compile harfbuzz in `target=debug` with MinGW/GCC,
but there doesn't seem to be any drawback to enabling `/bigobj` (aside from
losing support for pre-VS 2005 linkers, which we don't support).
- 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.
First implementation with Linux display manager.
- Add single-threaded mode for EditorResourcePreview (needed for OpenGL).
Co-authored-by: clayjohn <claynjohn@gmail.com>
Co-authored-by: Fabio Alessandrelli <fabio.alessandrelli@gmail.com>
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.
Exposes AddressSanitizer support in MSVC compiler. Can be installed via individual
components in the Visual Studio 2019 Installer.
Disabled by default. Compile the engine with `scons use_asan=yes`.
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.
`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.
We want debug builds to have a console and easy stdout redirection by default.
Windows makes reading the stdout/stderr stream from gui applications too cumbersome
(and most users don't know about it, and just wonder why they don't see a thing).
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.
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?
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.
- 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.
The new 'split_libmodules=yes' option is useful to work around linker
command line size limitations when linking a huge number of objects.
We're currently over 64k chars when linking libmodules.a on Windows
with MinGW, which triggers issues as seen in #30892.
Even on Linux, we can also reach linker command line size limitations
by adding more custom modules.
We force this option to True for MinGW on Windows, which fixes#30892.
Additional changes to lib splitting:
- Fix linking of the split module libs with interdependent symbols,
hacking our way into LINKCOM and SHLINKCOM to set the `--start-group`
and `--end-group` flags.
- Fix Python 3 compatibility in `methods.split_lib()`.
- Drop seemingly obsolete condition for 'msys' on 'posix'.
- Drop the unnecessary 'split_drivers' as the drivers lib is no longer
too big since we moved all thirdparty builds to modules.
Co-authored-by: Hein-Pieter van Braam-Stewart <hp@tmm.cx>
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.
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.
