profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/DJMcNab/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Daniel McNab DJMcNab United Kingdom

DJMcNab/awesome-bevy 0

A collection of awesome Bevy projects

DJMcNab/bevy 0

A refreshingly simple data-driven game engine built in Rust

DJMcNab/bevy-crate-reservations 0

Reserved crates.io crate names. Contact us if you think your project needs one of these names!

DJMcNab/bytemuck 0

A crate for mucking around with piles of bytes

DJMcNab/cargo 0

The Rust package manager

DJMcNab/compute-shader-101 0

Sample code for compute shader 101 training

DJMcNab/druid 0

A data-first Rust-native UI design toolkit.

DJMcNab/language-server-protocol 0

Defines a common protocol for language servers.

DJMcNab/lerna 0

:dragon: A tool for managing JavaScript projects with multiple packages.

push eventDJMcNab/rust-gpu

Daniel McNab

commit sha 10096636a76d0bac5dd4daf0b3e5614230031d87

Re-export `Image` from the root Fix the doc comment to point to the correct one, as it would be now ambiguous This is because both the `Image` macro and struct are exported from the root

view details

Daniel McNab

commit sha 16db4f83c764c87c6f613f333f841f4ffa47c6d1

Re-create the export

view details

push time in 7 minutes

Pull request review commentEmbarkStudios/rust-gpu

Fix `cargo test`

 mod params;  pub use self::params::{ImageCoordinate, ImageCoordinateSubpassData, SampleType};+/// A macro for creating SPIR-V `OpTypeImage` types. Always produces a+/// [`spirv_std::image::Image<...>`](struct@Image) type.+///+/// The grammar for the macro is as follows:+///+/// ```rust+/// # // This doctest can't use the normal macro, use an alternative version+/// # macro_rules! Image {+/// #   ($($tt: tt)*)=> {}+/// # }+/// Image!(+///     <dimensionality>,+///     <type=...|format=...>,+///     [sampled[=<true|false>],]+///     [multisampled[=<true|false>],]+///     [arrayed[=<true|false>],]+///     [depth[=<true|false>],]+/// )+/// # ;+/// ```+///+/// `=true` can be omitted as shorthand - e.g. `sampled` is short for `sampled=true`.+///+/// A basic example looks like this:+/// ```rust,no_run+/// # // This doctest should compile, but we disable doctests for this crate anyway+/// # // because this single test isn't worth the compile time cost+/// # use spirv_std::macros::{spirv, Image};+/// #[spirv(vertex)]+/// fn main_vs(#[spirv(descriptor_set = 0, binding = 0)] image: &Image!(2D, type=f32, sampled)) {}+/// ```+///+/// ## Arguments+///+/// - `dimensionality` — Dimensionality of an image.+///    Accepted values: `1D`, `2D`, `3D`, `rect`, `cube`, `subpass`.+/// - `type` — The sampled type of an image, mutually exclusive with `format`,+///    when set the image format is unknown.+///    Accepted values: `f32`, `f64`, `u8`, `u16`, `u32`, `u64`, `i8`, `i16`, `i32`, `i64`.+/// - `format` — The image format of the image, mutually exclusive with `type`.+///    Accepted values: Snake case versions of [`ImageFormat`].+/// - `sampled` — Whether it is known that the image will be used with a sampler.+///    Accepted values: `true` or `false`. Default: `unknown`.+/// - `multisampled` — Whether the image contains multisampled content.+///    Accepted values: `true` or `false`. Default: `false`.+/// - `arrayed` — Whether the image contains arrayed content.+///    Accepted values: `true` or `false`. Default: `false`.+/// - `depth` — Whether it is known that the image is a depth image.+///    Accepted values: `true` or `false`. Default: `unknown`.+///+/// [`ImageFormat`]: spirv_types::image_params::ImageFormat+///+/// Keep in mind that `sampled` here is a different concept than the `SampledImage` type:+/// `sampled=true` means that this image requires a sampler to be able to access, while the+/// `SampledImage` type bundles that sampler together with the image into a single type (e.g.+/// `sampler2D` in GLSL, vs. `texture2D`).

How much do we actually care about the macro crate docs?

That is, would we be better off serving all of the macros as spirv_std::whatever, e.g. by using #[doc(inline)] on re-exports?

DJMcNab

comment created time in 13 minutes

PullRequestReviewEvent

Pull request review commentEmbarkStudios/rust-gpu

Fix `cargo test`

 pub(crate) mod sealed; pub mod vector;  pub use self::sampler::Sampler;-pub use crate::macros::Image;

Documentation of re-exports is not copied into re-exports of the re-export (i.e. no matter how we use this without duplicating the doc comment from spirv_std::image::Image!, we'll only get the docs from the macro in spirv_std_macros).

One alternative would be to make a macro Image in spirv_std which just calls spirv_std::macros::Image, which should work. But it would be nicer just not to have this re-re-export at the root.

DJMcNab

comment created time in 6 hours

PullRequestReviewEvent

Pull request review commentEmbarkStudios/rust-gpu

Fix `cargo test`

 pub(crate) mod sealed; pub mod vector;  pub use self::sampler::Sampler;-pub use crate::macros::Image;

Makes sense, can do

Imo, we should choose one canonical place and stick with it, whether that's inside or outside of the image module of spirv_std

DJMcNab

comment created time in 8 hours

PullRequestReviewEvent

Pull request review commentEmbarkStudios/rust-gpu

Fix `cargo test`

 mod params;  pub use self::params::{ImageCoordinate, ImageCoordinateSubpassData, SampleType};+/// A macro for creating SPIR-V `OpTypeImage` types. Always produces a+/// [`spirv_std::image::Image<...>`](struct@Image) type.+///+/// The grammar for the macro is as follows:+///+/// ```rust+/// # // This doctest can't use the normal macro, use an alternative version+/// # macro_rules! Image {+/// #   ($($tt: tt)*)=> {}+/// # }+/// Image!(+///     <dimensionality>,+///     <type=...|format=...>,+///     [sampled[=<true|false>],]+///     [multisampled[=<true|false>],]+///     [arrayed[=<true|false>],]+///     [depth[=<true|false>],]+/// )+/// # ;+/// ```+///+/// `=true` can be omitted as shorthand - e.g. `sampled` is short for `sampled=true`.+///+/// A basic example looks like this:+/// ```rust,no_run+/// # // This doctest should compile, but we disable doctests for this crate anyway+/// # // because this single test isn't worth the compile time cost+/// # use spirv_std::macros::{spirv, Image};+/// #[spirv(vertex)]+/// fn main_vs(#[spirv(descriptor_set = 0, binding = 0)] image: &Image!(2D, type=f32, sampled)) {}+/// ```+///+/// ## Arguments+///+/// - `dimensionality` — Dimensionality of an image.+///    Accepted values: `1D`, `2D`, `3D`, `rect`, `cube`, `subpass`.+/// - `type` — The sampled type of an image, mutually exclusive with `format`,+///    when set the image format is unknown.+///    Accepted values: `f32`, `f64`, `u8`, `u16`, `u32`, `u64`, `i8`, `i16`, `i32`, `i64`.+/// - `format` — The image format of the image, mutually exclusive with `type`.+///    Accepted values: Snake case versions of [`ImageFormat`].+/// - `sampled` — Whether it is known that the image will be used with a sampler.+///    Accepted values: `true` or `false`. Default: `unknown`.+/// - `multisampled` — Whether the image contains multisampled content.+///    Accepted values: `true` or `false`. Default: `false`.+/// - `arrayed` — Whether the image contains arrayed content.+///    Accepted values: `true` or `false`. Default: `false`.+/// - `depth` — Whether it is known that the image is a depth image.+///    Accepted values: `true` or `false`. Default: `unknown`.+///+/// [`ImageFormat`]: spirv_types::image_params::ImageFormat+///+/// Keep in mind that `sampled` here is a different concept than the `SampledImage` type:+/// `sampled=true` means that this image requires a sampler to be able to access, while the+/// `SampledImage` type bundles that sampler together with the image into a single type (e.g.+/// `sampler2D` in GLSL, vs. `texture2D`).

Ah, interesting

I only added that doc comment as a last minute thing before I had to go again

I think the best way is just to turn it into a normal comment.

DJMcNab

comment created time in 8 hours

PullRequestReviewEvent

push eventDJMcNab/rust-gpu

Daniel McNab

commit sha 9e7bcb2bffbe8adba7d89ae6ff0b524ee26c9a77

Document the image macro in spirv_std instead Workaround recommended by https://github.com/rust-lang/rust/issues/74481#issuecomment-808789257 Also fixes both of the doctests to be runnable

view details

Daniel McNab

commit sha 452b37eb2cc1cd161019c638c7a31368c13769db

Don't export the `Image` macro from the root I think it's better to have it next to the struct it constructs Additionally, nowhere else uses it through this alias

view details

push time in 8 hours

pull request commentbevyengine/bevy

Add webp support to texture loader

I think there are places where we document our features

We need to do this for this one (we should also mention that it uses native libraries, so will be more difficult to build for someone)

hanabi1224

comment created time in 12 hours

pull request commentEmbarkStudios/rust-gpu

Fix `cargo test`

Unfortunately, making sure that cargo test doesn't regress is the root cause of the extra compile time, because it's now trying to test the example runners and the shaders (for example, cargo test would regress again if we added a failing test for the collatz example).

That being said, I guess targeted only testing the specific crates which do have tests does make sense - it's just rather unfortunate that it leaves the door open for cargo test to silently regress again. I'll aim to move to that version at lunchtime

An alternative could be adding a single extra job which runs all of the tests on one platform - that one wouldn't have to use release mode so it should be relatively faster.

DJMcNab

comment created time in 14 hours

push eventDJMcNab/rust-gpu

Daniel McNab

commit sha c0ef63826c883f90736fbc51df9437143710f394

Remove the check of the examples These are already workspace members, so get checked by `cargo test`

view details

push time in a day

push eventDJMcNab/rust-gpu

Daniel McNab

commit sha 32bf9661c15951174a372103b55e88faf7505e74

Sync up the test stages

view details

push time in a day

startedh3r2tic/dolly

started time in a day

PR opened EmbarkStudios/rust-gpu

Fix `cargo test`

Also test a full cargo test in CI

I'm not certain that this change will work, but it does work locally

Lets see what CI does.

+12 -6

0 comment

4 changed files

pr created time in a day

create barnchDJMcNab/rust-gpu

branch : ci

created branch time in a day

pull request commentbevyengine/bevy

Re-export RandomState from ahash

I think I'd rather not expose this - ideally which hasher crate we use here should be an implementation detail

That being said, I'm not going to advocate against merging.

TheLeonsver1

comment created time in 2 days

issue commentbevyengine/bevy

Transform looking_at its different to Mat4 look_at_rh

Likely a duplicate of https://github.com/bevyengine/bevy/issues/1153

superdump

comment created time in 3 days

push eventDJMcNab/bevy

Daniel McNab

commit sha ca731048d819b1bb5a09224107dbcb5e3c407793

Use usize::MAX `usize::max_value` is deprecated

view details

Daniel McNab

commit sha ee8c6f6352df15c87f37dd541744b04ff7f57699

Rework `resolve_unknown_gen` Previously, it paniced when the value was out of the range, it now returns an Option. It was also erroniously marked as `unsafe`, even though it is a safe method I've renamed it - hopefully this rename makes sense I've also reworked `contains` to use this method, which allows it to be more precise about out-of-range entities.

view details

Daniel McNab

commit sha 3e7bd433a3183cfe9468f1ae2e3dd1a1b0a10c7a

Add a doc comment for len

view details

Daniel McNab

commit sha dbff6bf28965fac103da6f4cf6ea6af00bb2b21a

Ensure that the entity exists in `EntityCommands`

view details

Daniel McNab

commit sha 8b44eee466be2941006c349929d049761337e45b

Add type name to the error messages In release mode, these names might sometimes get lost from the call stack due to inlining

view details

Daniel McNab

commit sha 37ca8ff78683bf5e81cf05d43ab69355e6e19ea0

Change the debug message style to match the others Also change it to a warning TODO: Should this panic instead?

view details

Daniel McNab

commit sha bbe568e0218fa5e497b2b0ca1e6cbaae3855ab1a

Remove the spawn command It's ~~free real estate~~ dead code

view details

push time in 3 days

pull request commentbevyengine/bevy

Add a Bevy Linter

Obviously, that specific lint should probably also be added as a bevy internal check

We could even steal cargo style reporting for that, although obviously our ability to select spans is a more limited.

Once we get editor integration in some form, we'd also want to wire up the warnings there

MinerSebas

comment created time in 4 days

delete branch DJMcNab/bevy

delete branch : dynamic_plugin

delete time in 4 days

Pull request review commentbevyengine/bevy

Add error messages for the spooky insertions

 where     T: Bundle + 'static, {     fn write(self, world: &mut World) {-        world.entity_mut(self.entity).insert_bundle(self.bundle);+        if let Some(mut entity) = world.get_entity_mut(self.entity) {+            entity.insert_bundle(self.bundle);+        } else {+            panic!("Could not insert a bundle for entity {:?} because it no longer exists.\n\

Perhaps? I think that making error messages 'worse' because someone has manually created an entity id is not the tradeoff I'd prefer to make.

We can change this to "doesn't exist" though if you're adamant.

DJMcNab

comment created time in 4 days

PullRequestReviewEvent

push eventDJMcNab/bevy

Daniel McNab

commit sha b048a18c1eeac16d9290e2c569432a229a3f619b

Fixup typos Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

view details

push time in 4 days

PR opened bevyengine/bevy

Add error messages for the spooky insertions

Objective

Sometimes, the unwraps in entity_mut could fail here, if the entity was despawned before this command was applied.

The simplest case involves two command buffers:

use bevy::prelude::*;
fn b(mut commands1: Commands, mut commands2: Commands) {
    let id = commands2.spawn().insert_bundle(()).id();
    commands1.entity(id).despawn();
}
fn main() {
    App::build().add_system(b.system()).run();
}

However, a more complicated version arises in the case of ambiguity:

use std::time::Duration;

use bevy::{app::ScheduleRunnerPlugin, prelude::*};
use rand::Rng;

fn cleanup(mut e: ResMut<Option<Entity>>) {
    *e = None;
}

fn sleep_randomly() {
    let mut rng = rand::thread_rng();
    std::thread::sleep(Duration::from_millis(rng.gen_range(0..50)));
}

fn spawn(mut commands: Commands, mut e: ResMut<Option<Entity>>) {
    *e = Some(commands.spawn().insert_bundle(()).id());
}

fn despawn(mut commands: Commands, e: Res<Option<Entity>>) {
    let mut rng = rand::thread_rng();
    std::thread::sleep(Duration::from_millis(rng.gen_range(0..50)));
    if let Some(e) = *e {
        commands.entity(e).despawn();
    }
}

fn main() {
    App::build()
        .add_system(cleanup.system().label("cleanup"))
        .add_system(sleep_randomly.system().label("before_despawn"))
        .add_system(despawn.system().after("cleanup").after("before_despawn"))
        .add_system(sleep_randomly.system().label("before_spawn"))
        .add_system(spawn.system().after("cleanup").after("before_spawn"))
        .insert_resource(None::<Entity>)
        .add_plugin(ScheduleRunnerPlugin::default())
        .run();
}

In the cases where this example crashes, it's because despawn was ordered before spawn in the topological ordering of systems (which determines when buffers are applied). However, despawn actually ran after spawn, because these systems are ambiguous, so the jiggles in the sleeping time triggered a case where this works.

Solution

  • Give a better error message
+14 -2

0 comment

1 changed file

pr created time in 4 days

create barnchDJMcNab/bevy

branch : jeepers-creepers

created branch time in 4 days

PR opened bevyengine/bevy

Remove bevy_dynamic_plugin as a default

It doesn't compile on wasm, and it's full of footguns

Objective

  • If bevy is used with default features on wasm, there's more of a chance it will compile
  • Note that I haven't done a full audit - it's possible that there are other problematic crates

Solution

  • bevy_dynamic_plugin is no longer a default plugin
  • I've also done an accidental drive by reformatting of the root Cargo.toml, as I have Even Better Toml installed.
  • (Please, rustfmt do this for us)
+11 -6

0 comment

2 changed files

pr created time in 5 days

create barnchDJMcNab/bevy

branch : dynamic_plugin

created branch time in 5 days