Up to date
This page is up to date for Godot 4.2.
If you still find outdated information, please open an issue.
Engine¶
Inherits: Object
Provides access to engine properties.
Description¶
The Engine singleton allows you to query and modify the project's run-time parameters, such as frames per second, time scale, and others.
Properties¶
|
||
|
||
|
||
|
||
|
||
|
Methods¶
get_architecture_name ( ) const |
|
get_author_info ( ) const |
|
get_copyright_info ( ) const |
|
get_donor_info ( ) const |
|
get_frames_drawn ( ) |
|
get_frames_per_second ( ) const |
|
get_license_info ( ) const |
|
get_license_text ( ) const |
|
get_main_loop ( ) const |
|
get_physics_frames ( ) const |
|
get_physics_interpolation_fraction ( ) const |
|
get_process_frames ( ) const |
|
get_script_language ( int index ) const |
|
get_singleton ( StringName name ) const |
|
get_singleton_list ( ) const |
|
get_version_info ( ) const |
|
get_write_movie_path ( ) const |
|
has_singleton ( StringName name ) const |
|
is_editor_hint ( ) const |
|
is_in_physics_frame ( ) const |
|
register_script_language ( ScriptLanguage language ) |
|
void |
register_singleton ( StringName name, Object instance ) |
unregister_script_language ( ScriptLanguage language ) |
|
void |
unregister_singleton ( StringName name ) |
Property Descriptions¶
int max_fps = 0
The maximum number of frames per second that can be rendered. A value of 0 means "no limit". The actual number of frames per second may still be below this value if the CPU or GPU cannot keep up with the project logic and rendering.
Limiting the FPS can be useful to reduce system power consumption, which reduces heat and noise emissions (and improves battery life on mobile devices).
If ProjectSettings.display/window/vsync/vsync_mode is Enabled or Adaptive, it takes precedence and the forced FPS number cannot exceed the monitor's refresh rate.
If ProjectSettings.display/window/vsync/vsync_mode is Enabled, on monitors with variable refresh rate enabled (G-Sync/FreeSync), using a FPS limit a few frames lower than the monitor's refresh rate will reduce input lag while avoiding tearing.
If ProjectSettings.display/window/vsync/vsync_mode is Disabled, limiting the FPS to a high value that can be consistently reached on the system can reduce input lag compared to an uncapped framerate. Since this works by ensuring the GPU load is lower than 100%, this latency reduction is only effective in GPU-bottlenecked scenarios, not CPU-bottlenecked scenarios.
See also physics_ticks_per_second and ProjectSettings.application/run/max_fps.
int max_physics_steps_per_frame = 8
Controls the maximum number of physics steps that can be simulated each rendered frame. The default value is tuned to avoid "spiral of death" situations where expensive physics simulations trigger more expensive simulations indefinitely. However, the game will appear to slow down if the rendering FPS is less than 1 / max_physics_steps_per_frame of physics_ticks_per_second. This occurs even if delta is consistently used in physics calculations. To avoid this, increase max_physics_steps_per_frame if you have increased physics_ticks_per_second significantly above its default value.
float physics_jitter_fix = 0.5
Controls how much physics ticks are synchronized with real time. For 0 or less, the ticks are synchronized. Such values are recommended for network games, where clock synchronization matters. Higher values cause higher deviation of the in-game clock and real clock but smooth out framerate jitters. The default value of 0.5 should be fine for most; values above 2 could cause the game to react to dropped frames with a noticeable delay and are not recommended.
Note: For best results, when using a custom physics interpolation solution, the physics jitter fix should be disabled by setting physics_jitter_fix to 0.
int physics_ticks_per_second = 60
The number of fixed iterations per second. This controls how often physics simulation and Node._physics_process methods are run. This value should generally always be set to 60 or above, as Godot doesn't interpolate the physics step. As a result, values lower than 60 will look stuttery. This value can be increased to make input more reactive or work around collision tunneling issues, but keep in mind doing so will increase CPU usage. See also max_fps and ProjectSettings.physics/common/physics_ticks_per_second.
Note: Only max_physics_steps_per_frame physics ticks may be simulated per rendered frame at most. If more physics ticks have to be simulated per rendered frame to keep up with rendering, the project will appear to slow down (even if delta is used consistently in physics calculations). Therefore, it is recommended to also increase max_physics_steps_per_frame if increasing physics_ticks_per_second significantly above its default value.
bool print_error_messages = true
If false, stops printing error and warning messages to the console and editor Output log. This can be used to hide error and warning messages during unit test suite runs. This property is equivalent to the ProjectSettings.application/run/disable_stderr project setting.
Warning: If you set this to false anywhere in the project, important error messages may be hidden even if they are emitted from other scripts. If this is set to false in a @tool script, this will also impact the editor itself. Do not report bugs before ensuring error messages are enabled (as they are by default).
Note: This property does not impact the editor's Errors tab when running a project from the editor.