mirror of
https://github.com/bevyengine/bevy
synced 2024-11-26 06:30:19 +00:00
5c52d0aeee
# Objective Add interactive system debugging capabilities to bevy, providing step/break/continue style capabilities to running system schedules. * Original implementation: #8063 - `ignore_stepping()` everywhere was too much complexity * Schedule-config & Resource discussion: #8168 - Decided on selective adding of Schedules & Resource-based control ## Solution Created `Stepping` Resource. This resource can be used to enable stepping on a per-schedule basis. Systems within schedules can be individually configured to: * AlwaysRun: Ignore any stepping state and run every frame * NeverRun: Never run while stepping is enabled - this allows for disabling of systems while debugging * Break: If we're running the full frame, stop before this system is run Stepping provides two modes of execution that reflect traditional debuggers: * Step-based: Only execute one system at a time * Continue/Break: Run all systems, but stop before running a system marked as Break ### Demo https://user-images.githubusercontent.com/857742/233630981-99f3bbda-9ca6-4cc4-a00f-171c4946dc47.mov Breakout has been modified to use Stepping. The game runs normally for a couple of seconds, then stepping is enabled and the game appears to pause. A list of Schedules & Systems appears with a cursor at the first System in the list. The demo then steps forward full frames using the spacebar until the ball is about to hit a brick. Then we step system by system as the ball impacts a brick, showing the cursor moving through the individual systems. Finally the demo switches back to frame stepping as the ball changes course. ### Limitations Due to architectural constraints in bevy, there are some cases systems stepping will not function as a user would expect. #### Event-driven systems Stepping does not support systems that are driven by `Event`s as events are flushed after 1-2 frames. Although game systems are not running while stepping, ignored systems are still running every frame, so events will be flushed. This presents to the user as stepping the event-driven system never executes the system. It does execute, but the events have already been flushed. This can be resolved by changing event handling to use a buffer for events, and only dropping an event once all readers have read it. The work-around to allow these systems to properly execute during stepping is to have them ignore stepping: `app.add_systems(event_driven_system.ignore_stepping())`. This was done in the breakout example to ensure sound played even while stepping. #### Conditional Systems When a system is stepped, it is given an opportunity to run. If the conditions of the system say it should not run, it will not. Similar to Event-driven systems, if a system is conditional, and that condition is only true for a very small time window, then stepping the system may not execute the system. This includes depending on any sort of external clock. This exhibits to the user as the system not always running when it is stepped. A solution to this limitation is to ensure any conditions are consistent while stepping is enabled. For example, all systems that modify any state the condition uses should also enable stepping. #### State-transition Systems Stepping is configured on the per-`Schedule` level, requiring the user to have a `ScheduleLabel`. To support state-transition systems, bevy generates needed schedules dynamically. Currently it’s very difficult (if not impossible, I haven’t verified) for the user to get the labels for these schedules. Without ready access to the dynamically generated schedules, and a resolution for the `Event` lifetime, **stepping of the state-transition systems is not supported** --- ## Changelog - `Schedule::run()` updated to consult `Stepping` Resource to determine which Systems to run each frame - Added `Schedule.label` as a `BoxedSystemLabel`, along with supporting `Schedule::set_label()` and `Schedule::label()` methods - `Stepping` needed to know which `Schedule` was running, and prior to this PR, `Schedule` didn't track its own label - Would have preferred to add `Schedule::with_label()` and remove `Schedule::new()`, but this PR touches enough already - Added calls to `Schedule.set_label()` to `App` and `World` as needed - Added `Stepping` resource - Added `Stepping::begin_frame()` system to `MainSchedulePlugin` - Run before `Main::run_main()` - Notifies any `Stepping` Resource a new render frame is starting ## Migration Guide - Add a call to `Schedule::set_label()` for any custom `Schedule` - This is only required if the `Schedule` will be stepped --------- Co-authored-by: Carter Anderson <mcanders1@gmail.com>
5.4 KiB
5.4 KiB
Cargo Features
Bevy exposes many features to customise the engine. Enabling them add functionalities but often come at the cost of longer compilation times and extra dependencies.
Default Features
The default feature set enables most of the expected features of a game engine, like rendering in both 2D and 3D, asset loading, audio and UI. To help reduce compilation time, consider disabling default features and enabling only those you need.
| feature name | description |
|---|---|
| android_shared_stdcxx | Enable using a shared stdlib for cxx on Android |
| animation | Enable animation support, and glTF animation loading |
| bevy_animation | Provides animation functionality |
| bevy_asset | Provides asset functionality |
| bevy_audio | Provides audio functionality |
| bevy_core_pipeline | Provides cameras and other basic render pipeline features |
| bevy_debug_stepping | Enable stepping-based debugging of Bevy systems |
| bevy_gilrs | Adds gamepad support |
| bevy_gizmos | Adds support for rendering gizmos |
| bevy_gltf | glTF support |
| bevy_pbr | Adds PBR rendering |
| bevy_render | Provides rendering functionality |
| bevy_scene | Provides scene functionality |
| bevy_sprite | Provides sprite functionality |
| bevy_text | Provides text functionality |
| bevy_ui | A custom ECS-driven UI framework |
| bevy_winit | winit window and input backend |
| default_font | Include a default font, containing only ASCII characters, at the cost of a 20kB binary size increase |
| hdr | HDR image format support |
| ktx2 | KTX2 compressed texture support |
| multi-threaded | Enables multithreaded parallelism in the engine. Disabling it forces all engine tasks to run on a single thread. |
| png | PNG image format support |
| tonemapping_luts | Include tonemapping Look Up Tables KTX2 files. If everything is pink, you need to enable this feature or change the Tonemapping method on your Camera2dBundle or Camera3dBundle. |
| vorbis | OGG/VORBIS audio format support |
| webgl2 | Enable some limitations to be able to use WebGL2. Please refer to the WebGL2 and WebGPU section of the examples README for more information on how to run Wasm builds with WebGPU. |
| x11 | X11 display server support |
| zstd | For KTX2 supercompression |
Optional Features
| feature name | description |
|---|---|
| accesskit_unix | Enable AccessKit on Unix backends (currently only works with experimental screen readers and forks.) |
| asset_processor | Enables the built-in asset processor for processed assets. |
| async-io | Use async-io's implementation of block_on instead of futures-lite's implementation. This is preferred if your application uses async-io. |
| basis-universal | Basis Universal compressed texture support |
| bevy_ci_testing | Enable systems that allow for automated testing on CI |
| bevy_dynamic_plugin | Plugin for dynamic loading (using libloading) |
| bmp | BMP image format support |
| dds | DDS compressed texture support |
| debug_glam_assert | Enable assertions in debug builds to check the validity of parameters passed to glam |
| detailed_trace | Enable detailed trace event logging. These trace events are expensive even when off, thus they require compile time opt-in |
| dynamic_linking | Force dynamic linking, which improves iterative compile times |
| embedded_watcher | Enables watching in memory asset providers for Bevy Asset hot-reloading |
| exr | EXR image format support |
| file_watcher | Enables watching the filesystem for Bevy Asset hot-reloading |
| flac | FLAC audio format support |
| glam_assert | Enable assertions to check the validity of parameters passed to glam |
| jpeg | JPEG image format support |
| minimp3 | MP3 audio format support (through minimp3) |
| mp3 | MP3 audio format support |
| pbr_transmission_textures | Enable support for transmission-related textures in the StandardMaterial, at the risk of blowing past the global, per-shader texture limit on older/lower-end GPUs |
| pnm | PNM image format support, includes pam, pbm, pgm and ppm |
| serialize | Enable serialization support through serde |
| shader_format_glsl | Enable support for shaders in GLSL |
| shader_format_spirv | Enable support for shaders in SPIR-V |
| subpixel_glyph_atlas | Enable rendering of font glyphs using subpixel accuracy |
| symphonia-aac | AAC audio format support (through symphonia) |
| symphonia-all | AAC, FLAC, MP3, MP4, OGG/VORBIS, and WAV audio formats support (through symphonia) |
| symphonia-flac | FLAC audio format support (through symphonia) |
| symphonia-isomp4 | MP4 audio format support (through symphonia) |
| symphonia-vorbis | OGG/VORBIS audio format support (through symphonia) |
| symphonia-wav | WAV audio format support (through symphonia) |
| tga | TGA image format support |
| trace | Tracing support |
| trace_chrome | Tracing support, saving a file in Chrome Tracing format |
| trace_tracy | Tracing support, exposing a port for Tracy |
| trace_tracy_memory | Tracing support, with memory profiling, exposing a port for Tracy |
| wav | WAV audio format support |
| wayland | Wayland display server support |
| webgpu | Enable support for WebGPU in Wasm. When enabled, this feature will override the webgl2 feature and you won't be able to run Wasm builds with WebGL2, only with WebGPU. Requires the RUSTFLAGS environment variable to be set to --cfg=web_sys_unstable_apis when building. |
| webp | WebP image format support |
| wgpu_trace | Save a trace of all wgpu calls |
| zlib | For KTX2 supercompression |