Previous fix in e8e06b2 worked in most cases but not if you run e.g.
'godot -', where the '-' argument would mean that 'project_manager'
is false and yet that's what will be opened eventually.
This adds a static is_viable() method to all rasterizers which has to be
called before initializing the rasterizer. This allows us to check what
rasterizer to use in OS::initialize together with the GL context
initialization.
This commit also adds a new project setting
"rendering/quality/driver/driver_fallback" which allows the creator of a
project to specify whether or not fallback to GLES2 is allowed. This
setting is ignored for the editor so the editor will always open even if
the project itself cannot run. This will hopefully reduce confusion for
users downloading projects from the internet.
We also no longer crash when GLES3 is not functioning on a platform.
This fixes#15324
-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
The rasterisers (both GLES3 and GLES2) were calculating their own frame delta time
This fix lets the rasterizers get the frame delta through the draw call
That way any regulations to the frame step from the main script will not cause particle systems to process at a different step than the rest of the Engine.
Remove unused rasterizer storage variable
frame.prev_tick variable were not used anywhere and has been removed
- Adds q/quit option to console debugging
- Adds options (variable_prefix)
- Breaks into debugger with Ctrl-C in local debug mode (Unix/Windows)
- Added option to list all breakpoints
- Fixes add/remove breakpoint bug (invalid path parsing)
- Minor cleanup
- Tool scripts will be executed and can be accessed by plugins.
- Other script languages can implement add/remove_named_global_constant
to make use of this functionality.
Now generating mouse events from touch is optional (on by default) and it's performed by `InputDefault` instead of having each OS abstraction doing it. (*)
The translation algorithm waits for a touch index to be pressed and tracks it translating its events to mouse events until it is raised, while ignoring other pointers.
Furthermore, to avoid an stuck "touch mouse", since not all platforms may report touches raised when the window is unfocused, it checks if touches are still down by the time it's focused again and if so it resets the state of the emulated mouse.
*: In the case of Windows, since it already provides touch-to-mouse translation by itself, "echo" mouse events are filtered out to have it working like the rest.
On X11 a little hack has been needed to avoid a case of a spurious mouse motion event that is generated during touch interaction.
Plus: Improve/fix tracking of current mouse position.
** Summary of changes to settings: **
- `display/window/handheld/emulate_touchscreen` becomes `input/pointing_devices/emulate_touch_from_mouse`
- New setting: `input/pointing_devices/emulate_mouse_from_touch`
Add new class _TimerSync to manage timestep calculations.
The new class handles the decisions about simulation progression
previously handled by main::iteration(). It is fed the current timer
ticks and determines how many physics updates are to be run and what
the delta argument to the _process() functions should be.
The new class tries to keep the number of physics updates per frame as
constant as possible from frame to frame. Ideally, it would be N steps
every render frame, but even with perfectly regular rendering, the
general case is that N or N+1 steps are required per frame, for some
fixed N. The best guess for N is stored in typical_physics_steps.
When determining the number of steps to take, no restrictions are
imposed between the choice of typical_physics_steps and
typical_physics_steps+1 steps. Should more or less steps than that be
required, the accumulated remaining time (as before, stored in
time_accum) needs to surpass its boundaries by some minimal threshold.
Once surpassed, typical_physics_steps is updated to allow the new step
count for future updates.
Care is taken that the modified calculation of the number of physics
steps is not observable from game code that only checks the delta
parameters to the _process and _physics_process functions; in addition
to modifying the number of steps, the _process argument is modified as
well to stay in expected bounds. Extra care is taken that the accumulated
steps still sum up to roughly the real elapsed time, up to a maximum
tolerated difference.
To allow the hysteresis code to work correctly on higher refresh
monitors, the number of typical physics steps is not only recorded and
kept consistent for single render frames, but for groups of them.
Currently, up to 12 frames are grouped that way.
The engine parameter physics_jitter_fix controls both the maximum
tolerated difference between wall clock time and summed up _process
arguments and the threshold for changing typical_physics_steps. It is
given in units of the real physics frame slice 1/physics_fps. Set
physics_jitter_fix to 0 to disable the effects of the new code here.
It starts to be effective against the random physics jitter at around
0.02 to 0.05. at values greater than 1 it starts having ill effects on
the engine's ability to react sensibly to dropped frames and framerate
changes.
Works both for the editor and games.
Projects can still use "debug/settings/stdout/print_fps" to enable it
permanently. The --print-fps option takes precedence (so works even if
the project setting is disabled). That setting is also no longer redefined
on the fly based on the verbose flag, that was a mess.
After 3f8a4cc719 trying to run an
individual scene on a project without a main scene fails. We move the
check until after we've determined whether or not we're trying to run an
individual scene.
We also stop trying to show the project manager if any game pack is
found at all, unless the user explicitly asks for the project manager to
be shown.
The previous logic with VERSION_MKSTRING was a bit unwieldy, so there were
several places hardcoding their own variant of the version string, potentially
with bugs (e.g. forgetting the patch number when defined).
The new logic defines:
- VERSION_BRANCH, the main 'major.minor' version (e.g. 3.1)
- VERSION_NUMBER, which can be 'major.minor' or 'major.minor.patch',
depending on whether the latter is defined (e.g. 3.1.4)
- VERSION_FULL_CONFIG, which contains the version status (e.g. stable)
and the module-specific suffix (e.g. mono)
- VERSION_FULL_BUILD, same as above but with build/reference name
(e.g. official, custom_build, mageia, etc.)
Note: Slight change here, as the previous format had the build name
*before* the module-specific suffix; now it's after
- VERSION_FULL_NAME, same as before, so VERSION_FULL_BUILD prefixed
with "Godot v" for readability
Bugs fixed thanks to that:
- Export templates version matching now properly takes VERSION_PATCH
into account by relying on VERSION_FULL_CONFIG.
- ClassDB hash no longer takes the build name into account, but limits
itself to VERSION_FULL_CONFIG (build name is cosmetic, not relevant
for the API hash).
- Docs XML no longer hardcode the VERSION_STATUS, this was annoying.
- Small cleanup in Windows .rc file thanks to new macros.
The Project Manager should share the same settings as the editor most of the time.
The whole init stuff with Main::setup and Main::start needs a good cleanup though.
Fixes#15199.
