WM_MOUSEWHEEL and WM_MOUSEHWHEEL report mouse coordinates relative to
the screen (see lParam in [1]), rather than to the window like the rest
of the mouse events.
The current code already makes adjustments to take that into account.
However, it only makes the adjustments if the mouse is not captured, and
the coordinates are always relative to the screen regardless of whether
the mouse is captured or not, so let's fix the code to always
consistently apply the adjustments.
This fixes#29559.
[1] - https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-mousewheel
Currently, the console appears when running OS.execute in an exported project,
but not in the editor. This change prevents it from appearing in either.
Only affects console applications.
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.
This is an editor setting and its value can also be toggled
using an entry in the Editor toolbar. The console will still
appear briefly when starting the project manager or editor,
as it's still compiled as console application.
Does not impact exported games, which will still run without
console in release and with console in debug mode.
A project setting or export option could be added to disable
it in debug mode if there's demand for it, but that would
greatly reduce the usefulness of debug builds if Windows users
can no longer report error and crash messages.
Fixes#17889.
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
Warnings raised by Emscripten 1.38.0 and MinGW64 5.0.4 / GCC 8.3.0.
JS can now build with `werror=yes warnings=extra`.
MinGW64 still has a few warnings to resolve with `warnings=extra`,
and only one with `warnings=all`.
Part of #29033 and #29801.
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.
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).
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.
