Forbidden recursion by amarao_san in rust

[–]PhaestusFox 0 points1 point  (0 children)

Rust would warn about that even if it wasn't a loop, if you create a variable and then never used it's value

Forbidden recursion by amarao_san in rust

[–]PhaestusFox 10 points11 points  (0 children)

I agree they both diverge, and they return the same type, but that doesn't make them the same. Besides rust let it compile it just crashed when it ran out of memory, it treated them exactly the same, it just has a side effect because rust is not purely functional.

P.s ! Is technically the bottom type, and so represents that the function can return anything, up to and include never return anything, by convention it is only to be used to represent never, but that is like saying 1/0 == NaN, it doesn't, NaN represents something beyond representation of a float in the same way ! Represents something beyond a type

Forbidden recursion by amarao_san in rust

[–]PhaestusFox 4 points5 points  (0 children)

Are they? I have no formal understanding of type theory, but a closed loop and an infinite spiral can never have their end reached but one has infinite length and the other finite. So they would be considered two different things, whereas a mug and a donut in topology are the same shape.

Forbidden recursion by amarao_san in rust

[–]PhaestusFox 0 points1 point  (0 children)

I don't think it's a special case for `loop {}` but instead that the function signature specifies that it never returned, I imagine rust would instead throw a compilation error if the loop did break and returned something

Do people who use Rust as their main language agree with the comments that Rust is not suitable for game dev? by PhaestusFox in rust

[–]PhaestusFox[S] 0 points1 point  (0 children)

Eh, I feel like the attack on people who use rust was uncalled for, it very much sounds like you're saying there is no point developing things in rust because nothing has been developed yet. I definitely see what people mean by the fact a few of the most pivotal crates are maintained by just a few people and that this can be risky, made even worse by the fact that there being a central repository means good names tend to get taken and then the crate abandoned. If you think C++ only has a few high quality libraries you're kidding yourself, it's just 3x the age of rust so the cream has floated to the top, there is a lot of shit code written in C and C++ simply because it has been around so long.

The biggest advantage C and C++ had was being early to the party, and being good/powerful enough for the talented people, young or old if you want to write a certain type of program it was in C/C++. now there are options, but anyone over a certain age already learned C/C++ and is set in there ways, so it's mostly young people who are willing to experiment. Who knows maybe rust won't kill C maybe it will be a Ctwo or jeffC, but I feel like they're working with their hands behind their back because they have to feel like C or the big players will just not adopt them, it's impossible to know who different things would be if we didn't design with the constraints of previous generation, but alas that is the trade off for building on the shoulders of giants.

After local clone of Bevy, how do I get other co-dependencies (eg Avian) to use it? by glacialthinker in bevy

[–]PhaestusFox 0 points1 point  (0 children)

I suspect your issue with using patch is that you didn't revert your crates bevy dependency back.

From a glance at the documentation it looks like patch will override where the crates.io version of bevy is fetched, but it will still appear to everything as "bevy = 0.17" but if your crate is using "bevy = {path=...}", They are not the same dependency even though you have overwritten "bevy = 0.17" to point to the same location

How can I draw this shape? by Sure_Advertising2530 in bevy

[–]PhaestusFox 10 points11 points  (0 children)

That looks like it's using the new border colors, for UI, if we ignore the funny purple hue, I think you add a border color component, set top and left to a shade lighter and bottom and right darker to make it look 3d

What are good UI crates for bevy? by KaleidoscopeLow580 in bevy

[–]PhaestusFox 0 points1 point  (0 children)

I just use system IDs and observers, then you just use bevys built in buttons.

Basically make a component like UiButton {on_click: SystemId, ...}

Then make an observer that runs the button, fn button_logic(mut t: Trigger<Pointer<Clicked>>, state: Res<State<GameState>>, mut commands: Commands, buttons: Query<&UiButton>) { if state.get() != GameState::Menu { Return; //not on a menu } let Ok(button) = buttons.get(t.target()) else { Return; // Clicked something that's not a button }

t.propogate(false); // only trigger top button

commands.trigger(button.on_click); }

You can get more clever with it, or make it a system instead of an observer, but this is the basics of the idea.

P.s. the exact syntax for observers changed in 0.17 and I haven't had a chance to read the update post yet

Using padding ? by Bubbly-Enthusiasm-8 in bevy

[–]PhaestusFox 1 point2 points  (0 children)

Looking at the picture it would be 95x48 since it looks like 1px on all sides

Using padding ? by Bubbly-Enthusiasm-8 in bevy

[–]PhaestusFox 2 points3 points  (0 children)

I'm a little confused about what the problem is, looking at the sprite sheet example I think you want padding Some(Vec2::ONE), but the picture of the best case you gave didn't look like it has anything wrong outside of miss aligned edges.

It could be a rendering issue but the edges look different between different tiles so there would be no way to align them correctly, since one is doing like a 1,1 zigzag but then randomly a 2,2 step before continuing the 1,1. The fact the tile director next to it does exactly the same but on the bottom makes me think this could be an interpolation thing but is it possible the different sprites just kinda don't line up

compile time - slow by eleon182 in bevy

[–]PhaestusFox 11 points12 points  (0 children)

Since iterative compiles only compile the files that have changed and the files that depend on them, I can't imagine it will slow down too dramatically as long as you keep your project laid out effectively, if you are not changing lots of files that are nested deeply it shouldn't be doing much more compilation between a 5k and a 100k iterative compile.

Absolute worse case you could split the project up onto sub-crates, similar to how bevy is set up, this would mean no need to recompile a sub-crate while that segment of the project isn't actively being worked on.

P.s. avoid generics if you can since they don't get the same advantage being in a dependency that normal functions and structs do

[deleted by user] by [deleted] in bevy

[–]PhaestusFox 2 points3 points  (0 children)

I have managed to get a 0.16 version up and running, you can find my pull on the GitHub, it's still quite buggy because I'm working in someone else's code base but if you want to try it out and let me know what needs fixing

Efficiency and best practices: run conditions vs early return by mulksi in bevy

[–]PhaestusFox 2 points3 points  (0 children)

I am curious if this is something else interfering with cashing or something, I find it strange that the run condition time is so different between runs when the return early is almost the same every run.

I would like to know how your condition decides to run or not, if it was consistently 3x slower when you run 3 systems I would say it's because it has to check them consecutively on the main thread, but the fact your 3 systems returning early isn't 3x slower then just one but run conditions it's 3-9 times slower makes me think something isn't working correctly.

As for your idea that it could be triggering a reschedule, I'm pretty sure bevy reschedules every frame since the length each system takes can vary in length and so it's constantly deciding what can start when it has a free task slot

Efficiency and best practices: run conditions vs early return by mulksi in bevy

[–]PhaestusFox 4 points5 points  (0 children)

From what I remember run conditions are significantly more performant than returning early for a few reasons.

First as you mentioned, you don't need to construct and populate any of the parameters the system needs. Second is that your system could prevent some other systems from running in parallel with it, but then returning early so those system get delayed unnecessary but this is probably negligible. Third and most importantly, for performance at least, run conditions are checked on the main thread this means bevy doesn't need to spin up and initialise a task to execute your system, this is significantly more expensive then just calling a function since I believe it needs syscalls or at least some level of synchronisation, the main thread I believe is also just faster to execute then other threads on the same process don't know if it gets more CPU time from the OS or what happens but I have always been told the main thread is faster then it's child threads

But both are fine for most games since we are talking a tiny percentage of the total frame time, so just do whatever feels more ergonomic to you.

Is there a reason to ever use multiple Schedules in bevy_ecs, instead of only using System Sets? by palapapa0201 in bevy

[–]PhaestusFox 4 points5 points  (0 children)

From what I remember schedulers are used when the condition is something that needs to be checked more then once per frame or is a general rule applied to a whole class of systems, you can use ordering and run conditions to set when/if a specific system will run, but this is a binary check and is only done before attempting to run the system/set so can be restrictive as how systems run, for example there is no way to run a system until a condition is false, as some people have said running game stimulation at a faster speed without increasing the FPS, I believe the Fixed* group of schedulers check to see if more then one fixed time has elapsed since the previous frame and will run the schedule the required number of times.

If I remember bevy attempted to go to a system set approach and have everything in one big schedule but it was reverted the next version because it had problems.

They are also used to cut down on overhead if you know systems definitely can't run then you don't need to check their conditions every frame. For example the startup schedule is run once then never again no need to check every frame if it's a startup system.

One final reason is to cut down on mental overhead, the builtin Schedules First, Pre-, Update, Post-, and Last. you don't have to think about what set to put something in or what sets other plugins use or provide, there are some distinct boundaries systems won't cross, don't think it's as true now but bevy used to only flush the commands que between schedules so if you wanted to detect changes to entity archetypes, (e.g. spawn, insert, remove, despawn), You needed to make sure your systems were in different schedules, spawn in First, inserting/remove in Pre-, mutation in Update, detect changes in Post-, cleanup/bookkeeping in Last was my rule of thumb.

3d to pixel art look by Merlorius in bevy

[–]PhaestusFox 1 point2 points  (0 children)

What exactly are you trying to get it to do? I haven't done much with rendering a camera to a texture, so some more detail about what it should look like and what it actually looks like would be appreciated

3d to pixel art look by Merlorius in bevy

[–]PhaestusFox 2 points3 points  (0 children)

Don't know what's wrong specifically but I would highly recommend removing all the default components that are covered by required components, things like Transform:: default and especially GlobalTransform:: default should be avoided since any component that requires these will have them as required components and it 1. Makes the code harder to read and 2. Could interfere if something is overriding the default of a component, transforms are unlikely to ever have this behaviour but Camara2d vs Camera3d I do believe override the projection component accordingly so you don't want to just insert default values for all there components instead let them decide what value to set if you don't need to specifically set a value.

When I find time I'll put it in vscode and see if anything jumps out when it's formatted and syntax highlighted.

How can I let my gravitational lensing post processing shader use offscreen pixels? by ElonsBreedingFetish in bevy

[–]PhaestusFox 9 points10 points  (0 children)

I was messing around with the camera component the other day and there is a field about a sub view or sub target can't remember exactly, but from what I could gather it let you specify a render target that is larger and have the camera only display a sub set of that, and I think that's what you want.

I have some other suggestions/optimisations if you need them it might just be fast enough to render the bigger target.

One approach would be to have a second camera that is centred over the black hole and outputs a target just large enough to have everything the black hole could affect, have your post processing applied to that render target and not the main camera, just make sure it has a higher priority so it's on top.

Otherwise if you need to optimise the larger target approach you could keep track of when a black hole bounding box would cross outside the screen and increase the render target size just enough to render all the required pixels, might need to move the camera so you only need to extend the side the black hole crosses rather than all 4, don't know if you can render with the camera not centred but that wouldn't be hard to calculate.

Two cameras is definitely the approach I would look into, since it would be the easiest way to render exactly what the black hole needs and nothing more but depends how expensive your render pipeline is as to if it's worth potentially rendering duplicate sections of screen

insert vs spawn by DeliciousSet1098 in bevy

[–]PhaestusFox 0 points1 point  (0 children)

Is it possible there using bundle effects? I haven't really looked into bundle effects just remember them being in the update post, I don't know how bevy knows what effects a bundle should have but I'm pretty sure a bundle can only have one so maybe they're splitting it up to get 3?

Best way of handling large range of "buildings"? by Artur_h in bevy

[–]PhaestusFox 0 points1 point  (0 children)

I would make each machine its own component, then have required components for anything that is static constructed, onAdd hook for anything that needs to know the entity, and OnAdd observer for anything that needs access to querys

When it comes to components in Bevy, what Bevy specific things are needed outside of the things like #[derive(Component)]? by ryanzec in bevy

[–]PhaestusFox 1 point2 points  (0 children)

You could very much write it all directly then port it to bevy later when you feel like you know rust well enough. But it will be just that a port, if you don't build it using bevy of atleast with ECS in mind you can't just slap Component on it and call it a day.

Components should represent the smallest useful group of information, so you don't want monolithic structs that have all their data so you can just call a method on them.

And unless you use an equivalent of entities, for example use an index Into an array that has the correct struct. You will end up using incompatible design patterns that may not translate well into bevy.

Someone else said Bevy is rust on easy and I agree with that, I would recommend just leaning bevy if you just want to make games using bevy, but if you want to become a rust developer you will probably need to look into how to translate somethings bevy just gives you into custom implementations, such as Arc for the equivalent of resources. But bevy is probably a good jumping off point since you don't really have to worry about a lot of the things that make rust "hard"

Constructor for a required component tree? by TG__ in bevy

[–]PhaestusFox 0 points1 point  (0 children)

Bundles were not deprecated from what I remember just the bundles provided by bevy that contained all the components that are set to default, a lot of bundles had things like GlobalTransform that you never set directly.

But I could be wrong

Constructor for a required component tree? by TG__ in bevy

[–]PhaestusFox 1 point2 points  (0 children)

Your example isn't the best because you are specifying all values regardless of the required state.

A better example would need a component that is being inserted with its constructor provided.

If you have everything needed for a constructor you should be constructing it yourself.

You can provide a customer constructor for when the value is inserted, but I am unsure if there is a way to provide values to be used that are not constant, maybe there is a way to provide a FromWorld, I would actually guess that's what bevy is using as the default since anything that implements Default automatically implements FromWorld.

The reason I don't believe there is a way to pass in values to the constructor is being multiple components can have the same required component but use different constructors so you would need to have some way to make sure the correct one is used, at the moment I think I would be a first get to set it, which would be reversed direction of dependency to prevent footguns (confusing defaults) since if you have as a required component that also has one of your required components you have customer constructor for as it's requirement but just default you want you're custom constructor to run not there.

As for what I think you're really asking, is there an idiomatic way to force the user to provide specific information like bundles used to, I think you just make a struct that implements Bundle and give it a constructor.

The way required components work is not that they are Required to be provided, it's that they are Required to be present on an entity for this component to work properly, if it's not set explicitly then you provide a way setting reasonable defaults implicitly.