Depth prepass

.cargo/config_fast_builds

@@ -1,20 +1,23 @@
-# Rename this file to `config.toml` to enable "fast build" configuration. Please read the notes below.
+# Add the contents of this file to `config.toml` to enable "fast build" configuration. Please read the notes below.
 
 # NOTE: For maximum performance, build using a nightly compiler
 # If you are using rust stable, remove the "-Zshare-generics=y" below.
 
 [target.x86_64-unknown-linux-gnu]
-linker = "/usr/bin/clang"
+linker = "clang"
 rustflags = ["-Clink-arg=-fuse-ld=lld", "-Zshare-generics=y"]
 
 # NOTE: you must manually install https://github.com/michaeleisel/zld on mac. you can easily do this with the "brew" package manager:
 # `brew install michaeleisel/zld/zld`
 [target.x86_64-apple-darwin]
-rustflags = ["-C", "link-arg=-fuse-ld=/usr/local/bin/zld", "-Zshare-generics=y", "-Zrun-dsymutil=no"]
+rustflags = ["-C", "link-arg=-fuse-ld=/usr/local/bin/zld", "-Zshare-generics=y"]
+
+[target.aarch64-apple-darwin]
+rustflags = ["-C", "link-arg=-fuse-ld=/opt/homebrew/bin/zld", "-Zshare-generics=y"]
 
 [target.x86_64-pc-windows-msvc]
 linker = "rust-lld.exe"
-rustflags = ["-Zshare-generics=y"]
+rustflags = ["-Zshare-generics=n"]
 
 # Optional: Uncommenting the following improves compile times, but reduces the amount of debug info to 'line number tables only'
 # In most cases the gains are negligible, but if you are on macos and have slow compile times you should see significant gains.

.gitattributes

@@ -0,0 +1,19 @@
+# From: https://docs.github.com/en/github/getting-started-with-github/configuring-git-to-handle-line-endings
+# Set the default behavior, in case people don't have core.autocrlf set.
+* text=auto
+
+# Explicitly declare text files you want to always be normalized and converted
+# to native line endings on checkout.
+*.rs text eol=lf
+*.toml text eol=lf
+*.frag text eol=lf
+*.vert text eol=lf
+*.wgsl text eol=lf
+
+# Declare files that will always have CRLF line endings on checkout.
+*.sln text eol=crlf
+
+# Denote all files that are truly binary and should not be modified.
+*.png binary
+*.jpg binary
+*.ttf binary

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,55 @@
+---
+name: Bug Report
+about: Report a bug to help us improve!
+title: ''
+labels: C-Bug, S-Needs-Triage
+assignees: ''
+---
+
+## Bevy version
+
+The release number or commit hash of the version you're using.
+
+## \[Optional\] Relevant system information
+
+If you cannot get Bevy to build or run on your machine, please include:
+
+- the Rust version you're using (you can get this by running `cargo --version`)
+  - Bevy relies on the "latest stable release" of Rust
+  - nightly should generally work, but there are sometimes regressions: please let us know!
+- the operating system or browser used, including its version
+  - e.g. Windows 10, Ubuntu 18.04, iOS 14
+
+If your bug is rendering-related, copy the adapter info that appears when you run Bevy.
+
+```ignore
+`AdapterInfo { name: "NVIDIA GeForce RTX 2070", vendor: 4318, device: 7938, device_type: DiscreteGpu, backend: Vulkan }`
+```
+
+You should also consider testing the examples of our upstream dependencies to help isolate any setup-specific issue:
+
+- [`wgpu`](https://github.com/gfx-rs/wgpu) for rendering problems
+- [`winit`](https://github.com/rust-windowing/winit) for input and window management
+- [`gilrs`](https://docs.rs/gilrs/latest/gilrs/) for gamepad inputs
+
+## What you did
+
+Describe how you arrived at the problem. If you can, consider providing a code snippet or link.
+
+## What went wrong
+
+If it's not clear, break this out into:
+
+- what were you expecting?
+- what actually happened?
+
+## Additional information
+
+Other information that can be used to further reproduce or isolate the problem.
+This commonly includes:
+
+- screenshots
+- logs
+- theories about what might be going wrong
+- workarounds that you used
+- links to related bugs, PRs or discussions

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,5 @@
+contact_links:
+  - name: Question
+    url: https://github.com/bevyengine/bevy/discussions/categories/q-a
+    about: Questions about how to use or contribute to Bevy belong in Github Discussions.
+      You can use the search to check if someone already answered your question!

.github/ISSUE_TEMPLATE/docs_improvement.md

@@ -0,0 +1,13 @@
+---
+name: Docs Improvement
+about: Help us write better docs to catch common issues!
+title: ''
+labels: C-Docs, S-Needs-Triage
+assignees: ''
+---
+
+## How can Bevy's documentation be improved?
+
+Provide a link to the documentation and describe how it could be improved. In what ways is it incomplete, incorrect, or misleading?
+
+If you have suggestions on exactly what the new docs should say, feel free to include them here. Or alternatively, make the changes yourself and [create a pull request](https://bevyengine.org/learn/book/contributing/code/) instead.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,24 @@
+---
+name: Feature Request
+about: Propose a new feature!
+title: ''
+labels: C-Enhancement, S-Needs-Triage
+assignees: ''
+---
+
+## What problem does this solve or what need does it fill?
+
+A description of why this particular feature should be added.
+
+## What solution would you like?
+
+The solution you propose for the problem presented.
+
+## What alternative(s) have you considered?
+
+Other solutions to solve and/or work around the problem presented.
+
+## Additional context
+
+Any other information you would like to add such as related previous work,
+screenshots, benchmarks, etc.

.github/bors.toml

@@ -0,0 +1,20 @@
+status = [
+    "build (windows-latest)",
+    "build (ubuntu-latest)",
+    "build (macos-latest)",
+    "build-wasm",
+    "build-android",
+    "markdownlint",
+    "run-examples",
+    "run-examples-on-wasm",
+    "check-doc",
+    "check-missing-examples-in-docs",
+    # "check-unused-dependencies",
+    "ci",
+    "check-compiles",
+    "build-and-install-on-iOS",
+    "run-examples-on-windows-dx12",
+]
+
+use_squash_merge = true
+block_labels = ["S-Pre-Relicense"]

.github/contributing/engine_style_guide.md

@@ -0,0 +1,38 @@
+# Style guide: Engine
+
+## Contributing
+
+For more advice on contributing to the engine, see the [relevant section](../../CONTRIBUTING.md#Contributing-your-own-ideas) of `CONTRIBUTING.md`.
+
+## General guidelines
+
+1. Prefer granular imports over glob imports like `bevy_ecs::prelude::*`.
+2. Use a consistent comment style:
+   1. `///` doc comments belong above `#[derive(Trait)]` invocations.
+   2. `//` comments should generally go above the line in question, rather than in-line.
+   3. Avoid `/* */` block comments, even when writing long comments.
+   4. Use \`variable_name\` code blocks in comments to signify that you're referring to specific types and variables.
+   5. Start comments with capital letters. End them with a period if they are sentence-like.
+3. Use comments to organize long and complex stretches of code that can't sensibly be refactored into separate functions.
+
+## Rust API guidelines
+
+As a reference for our API development we are using the [Rust API guidelines][Rust API guidelines]. Generally, these should be followed, except for the following areas of disagreement:
+
+### Areas of disagreements
+
+Some areas mentioned in the [Rust API guidelines][Rust API guidelines] we do not agree with. These areas will be expanded whenever we find something else we do not agree with, so be sure to check these from time to time.
+
+> All items have a rustdoc example
+
+- This guideline is too strong and not applicable for everything inside of the Bevy game engine. For functionality that requires more context or needs a more interactive demonstration (such as rendering or input features), make use of the `examples` folder instead.
+
+> Examples use ?, not try!, not unwrap
+
+- This guideline is usually reasonable, but not always required.
+
+> Only smart pointers implement Deref and DerefMut
+
+- Generally a good rule of thumb, but we're probably going to deliberately violate this for single-element wrapper types like `Life(u32)`. The behavior is still predictable and it significantly improves ergonomics / new user comprehension.
+
+[Rust API guidelines]: https://rust-lang.github.io/api-guidelines/about.html

.github/contributing/example_style_guide.md

@@ -0,0 +1,64 @@
+# Style guide: Examples
+
+For more advice on writing examples, see the [relevant section](../../CONTRIBUTING.md#writing-examples) of CONTRIBUTING.md.
+
+## Organization
+
+1. Examples should live in an appropriate subfolder of `/examples`.
+2. Examples should be a single file if possible.
+3. Assets live in `./assets`. Try to avoid adding new assets unless strictly necessary to keep the repo small. Don't add "large" asset files.
+4. Each example should try to follow this order:
+   1. Imports
+   2. A `fn main()` block
+   3. Example logic
+5. Try to structure app / plugin construction in the same fashion as the actual code.
+6. Examples should typically not have tests, as they are not directly reusable by the Bevy user.
+
+## Stylistic preferences
+
+1. Use simple, descriptive variable names.
+   1. Avoid names like `MyComponent` in favor of more descriptive terms like `Events`.
+   2. Prefer single letter differentiators like `EventsA` and `EventsB` to nonsense words like `EventsFoo` and `EventsBar`.
+   3. Avoid repeating the type of variables in their name where possible. For example, `Color` should be preferred to `ColorComponent`.
+2. Prefer glob imports of `bevy::prelude::*` and `bevy::sub_crate::*` over granular imports (for terseness).
+3. Use a consistent comment style:
+   1. `///` doc comments belong above `#[derive(Trait)]` invocations.
+   2. `//` comments should generally go above the line in question, rather than in-line.
+   3. Avoid `/* */` block comments, even when writing long comments.
+   4. Use \`variable_name\` code blocks in comments to signify that you're referring to specific types and variables.
+   5. Start comments with capital letters; end them with a period if they are sentence-like.
+4. Use comments to organize long and complex stretches of code that can't sensibly be refactored into separate functions.
+5. Avoid making variables `pub` unless it is needed for your example.
+
+## Code conventions
+
+1. Refactor configurable values ("magic numbers") out into constants with clear names.
+2. Prefer `for` loops over `.for_each`. The latter is faster (for now), but it is less clear for beginners, less idiomatic, and less flexible.
+3. Use `.single` and `.single_mut` where appropriate.
+4. In Queries, prefer `With<T>` filters over actually fetching unused data with `&T`.
+5. Prefer disjoint queries using `With` and `Without` over param sets when you need more than one query in a single system.
+6. Prefer structs with named fields over tuple structs except in the case of single-field wrapper types.
+7. Use enum-labels over string-labels for system / stage / etc. labels.
+
+## "Feature" examples
+
+These examples demonstrate the usage of specific engine features in clear, minimal ways.
+
+1. Focus on demonstrating exactly one feature in an example
+2. Try to keep your names divorced from the context of a specific game, and focused on the feature you are demonstrating.
+3. Where they exist, show good alternative approaches to accomplish the same task and explain why you may prefer one over the other.
+4. Examples should have a visible effect when run, either in the command line or a graphical window.
+
+## "Game" examples
+
+These examples show how to build simple games in Bevy in a cohesive way.
+
+1. Each of these examples lives in the [/examples/games] folder.
+2. Aim for minimum but viable status: the game should be playable and not obviously buggy but does not need to be polished, featureful, or terribly fun.
+3. Focus on code quality and demonstrating good, extensible patterns for users.
+   1. Make good use of enums and states to organize your game logic.
+   2. Keep components as small as possible but no smaller: all of the data on a component should generally be accessed at once.
+   3. Keep systems small: they should have a clear single purpose.
+   4. Avoid duplicating logic across similar entities whenever possible by sharing systems and components.
+4. Use `///` doc comments to explain what each function / struct does as if the example were part of a polished production codebase.
+5. Arrange your code into modules within the same file to allow for simple code folding / organization.

.github/dependabot.yml

@@ -4,8 +4,11 @@ updates:
     directory: /
     schedule:
       interval: weekly
-
+    labels:
+      - "C-Dependencies"
   - package-ecosystem: github-actions
     directory: /
     schedule:
       interval: weekly
+    labels:
+      - "C-Dependencies"

.github/example-run/alien_cake_addict.ron

@@ -0,0 +1,3 @@
+(
+    exit_after: Some(300)
+)

.github/example-run/breakout.ron

@@ -0,0 +1,3 @@
+(
+    exit_after: Some(900)
+)

.github/example-run/contributors.ron

@@ -0,0 +1,3 @@
+(
+    exit_after: Some(900)
+)

.github/example-run/load_gltf.ron

@@ -0,0 +1,3 @@
+(
+    exit_after: Some(300)
+)

.github/example-run/minimising.ron

@@ -0,0 +1,3 @@
+(
+    exit_after: Some(90)
+)

.github/example-run/no_renderer.ron

@@ -0,0 +1,3 @@
+(
+    exit_after: Some(100)
+)

.github/example-run/resizing.ron

@@ -0,0 +1,4 @@
+(
+    // Ensures that the full cycle will run
+    exit_after: Some(410)
+)

.github/example-run/scene.ron

@@ -0,0 +1,3 @@
+(
+    exit_after: Some(100)
+)

.github/linters/.markdown-lint.yml

@@ -0,0 +1,3 @@
+{
+    "MD013": false
+}

.github/pull_request_template.md

@@ -0,0 +1,27 @@
+# Objective
+
+- Describe the objective or issue this PR addresses.
+- If you're fixing a specific issue, say "Fixes #X".
+
+## Solution
+
+- Describe the solution used to achieve the objective above.
+
+---
+
+## Changelog
+
+> This section is optional. If this was a trivial fix, or has no externally-visible impact, you can delete this section.
+
+- What changed as a result of this PR?
+- If applicable, organize changes under "Added", "Changed", or "Fixed" sub-headings
+- Stick to one or two sentences. If more detail is needed for a particular change, consider adding it to the "Solution" section
+  - If you can't summarize the work, your change may be unreasonably large / unrelated. Consider splitting your PR to make it easier to review and merge!
+
+## Migration Guide
+
+> This section is optional. If there are no breaking changes, you can delete this section.
+
+- If this PR is a breaking change (relative to the last release of Bevy), describe how a user might need to migrate their code to support these changes
+- Simply adding new functionality is not a breaking change.
+- Fixing behavior that was definitely a bug, rather than a questionable design choice is not a breaking change.

.github/start-wasm-example/.gitignore

@@ -0,0 +1,4 @@
+node_modules/
+/test-results/
+/playwright-report/
+/playwright/.cache/