Input buffering is implicitly used by event accumulation, but this commit makes it more generic so it can be enabled for other uses.
For desktop OSs it's currently not feasible given main and UI threads are the same).
- API has been simplified: all events now go through `parse_input_event()`. Whether they are accumulated or not depends on the `use_accumulated_input` flag.
- Event accumulation is now thread-safe (it was not needed so far, but it prepares the ground for the following changes).
- Touch drag events now support accumulation.
The XDG Base Directory specification does not allow using relative paths
(which broke things in Godot anyway). If a relative path is detected,
it should be ignored.
(cherry picked from commits 011a99316a
and 0e1d45b210)
- Based on C++11's `thread` and `thread_local`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed (except for the few cases of non-portable functions)
- Simpler for `NO_THREADS`
- Thread ids are now the same across platforms (main is 1; others follow)
- Based on C++11's `mutex` and `condition_variable`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed
- Simpler for `NO_THREADS`
- Based on C++11's `mutex`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed
- Simpler for `NO_THREADS`
- `BinaryMutex` added for special cases as the non-recursive version
- `MutexLock` now takes a reference. At this point the cases of null `Mutex`es are rare. If you ever need that, just don't use `MutexLock`.
- `ScopedMutexLock` is dropped and replaced by `MutexLock`, because they were pretty much the same.
- Based on C++14's `shared_time_mutex`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed
- Simpler for `NO_THREADS`
Happy new year to the wonderful Godot community!
2020 has been a tough year for most of us personally, but a good year for
Godot development nonetheless with a huge amount of work done towards Godot
4.0 and great improvements backported to the long-lived 3.2 branch.
We've had close to 400 contributors to engine code this year, authoring near
7,000 commit! (And that's only for the `master` branch and for the engine code,
there's a lot more when counting docs, demos and other first-party repos.)
Here's to a great year 2021 for all Godot users 🎆
(cherry picked from commit b5334d14f7)
This makes these platform behave as MacOS in that regard and also fixes the editor window appearing in some cases even when --no-window has been passed.
The previous code for OS_Windows::get_ticks_usec() multiplied the tick count by 1000000 before dividing by ticks_per_second. The ticks is counted in a 64 bit integer and is susceptible to overflow when a machine has been running for a long period of time (days) with a high frequency timer.
This PR separates the overall calculation into one for seconds and one for the remainder, removing the possibility of overflow due to the multiplier.
(cherry picked from commit db9fa88160)
Affects per-pixel transparency
The current method renders to the screen by copying the GLES output to a
DIB for transparency using the CPU instead of rendering directly to the
window via the GPU. This is slower and also forces the window to be borderless
as WS_EX_LAYERED affects the non-client region as well.
This change uses DWMEnableBlurBehindWindow which allows using the standard
glClearColor() background alpha and is also performed through the GPU,
eliminating CPU bottlenecks
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.
This makes it possible to know whether the window is focused
at a given time, without having to track the focus state manually
using `NOTIFICATION_WM_FOCUS_IN` and `NOTIFICATION_WM_FOCUS_OUT`.
This partially addresses #33928.
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.
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.
When getting system directories for Windows, we currently use
SHGetFolderPathW. This is a deprecated function and doesn't support
"Downloads" folders.
As a replacement, this commit uses the newer SHGetKnownFolderPath
function, which is supported since Windows Vista. Godot 3.0 only
supports Windows 7+, so we don't need to use SHGetFolderPathW for
backwards compatibility.
Fixes#26876
It seems to stay compatible with formatting done by clang-format 6.0 and 7.0,
so contributors can keep using those versions for now (they will not undo those
changes).
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.
We've been defaulting to WASAPI since 3.0 and it's superior to RtAudio
in all aspects.
Obsoletes and closes#25503.
Also enable WINMIDI on MinGW, this had been missed initially.
Fix os_windows.cpp and crash_handler_windows.cpp which had weird
dependencies on RtAudio.h's includes (ugh).
