Position fighters transform relative to feet

[odecay]

Got collisions working as expected, moved hurtboxes to a child entity and added a Hurtbox component to mark them.

I think the size fighter meta property is going to cause confusion in addition to the already existing spritesheet size, although I recognize its usefulness since it can be a f32 and half the size of the actual spritesheet size to make operations using size simpler.
@zicklag is there a way to make a metadata property depend on/be defined by another metadata property? I think it would be best to keep size around and revert the spots where I changed to using spritesheet size, but have size be defined based off spritesheet size instead of being a redundant configurable property that we have to remember to set.

@edgarssilva I think this might also both break and make unnecessary the y-debug line plugin and maybe the YSort on fighters.
edit: I think the YSort would be good to keep in case we want to do virtual z axis stuff for jumping.

We also need to change the level bounds to accommodate for the translation that has taken place on y.
I haven't done this yet and also can't quite make sense of how the consts actually effect the offset/max y/min y
any suggestions there @edgarssilva?

Last thing is that I'm not sure the item pickup range is correct now.

There is also an alternative approach that could be taken, which is to keep the Hurtbox how it was, part of the fighter data but move the sprite to a child entity with an offset transform by half sprite_size.y and Anchor::BottomCenter, which would allow the collision stuff to stay the same as it was before. :edit have to think about that one more

[zicklag]

Looks good to me.

👍 for getting rid of setting two size values in the YAML.

I think what we can do is add #[serde(skip)] to the size field that we don't want the user to have to set, then when we load the fighter asset here we would use the spritesheet size to set the fighter size.

[edgarssilva]

We also need to change the level bounds to accommodate for the translation that has taken place on y. I haven't done this yet and also can't quite make sense of how the consts actually effect the offset/max y/min y any suggestions there @edgarssilva?

With the changes made the consts don't make as much sense but the GROUND_Y would be the Y of the middle of the ground sprite (I think now it has the full size with the top being transparent), GROUND_HEIGHT its height and GROUND_OFFSET a walkable offset to restraint movement. MIN_Y and MAX_Y are calculated from those.

To add or remove vertical walkable space you would change the value of GROUND_OFFSET but this is symmetrical if needed we could separate to top and bottom offset.

[edgarssilva]

@edgarssilva I think this might also both break and make unnecessary the y-debug line plugin and maybe the YSort on fighters. edit: I think the YSort would be good to keep in case we want to do virtual z axis stuff for jumping.

That was what I expected, the debug was more to easily see the math in play. If sorting is broken and you don't feel like fixing it just let me know and I'll check it out.

[odecay]

@edgarssilva I think this might also both break and make unnecessary the y-debug line plugin and maybe the YSort on fighters. edit: I think the YSort would be good to keep in case we want to do virtual z axis stuff for jumping.

That was what I expected, the debug was more to easily see the math in play. If sorting is broken and you don't feel like fixing it just let me know and I'll check it out.

Sorting broke momentarily but is fixed by not applying an offset in the YSort when spawning fighters, making some changes now but havent pushed commits yet.

[odecay]

We also need to change the level bounds to accommodate for the translation that has taken place on y. I haven't done this yet and also can't quite make sense of how the consts actually effect the offset/max y/min y any suggestions there @edgarssilva?

With the changes made the consts don't make as much sense but the GROUND_Y would be the Y of the middle of the ground sprite (I think now it has the full size with the top being transparent), GROUND_HEIGHT its height and GROUND_OFFSET a walkable offset to restraint movement. MIN_Y and MAX_Y are calculated from those.

To add or remove vertical walkable space you would change the value of GROUND_OFFSET but this is symmetrical if needed we could separate to top and bottom offset.

Ah okay helpful explanation. I think I understand, might make sense to make some changes so it would be something like MAX_Y and MIN_Y just correspond to the top and bottom of the stage sprite? (for sanity check, the bottom of the world/screen is Y=0 right? or is Y=0 at screen/world center)

[edgarssilva]

Ah okay helpful explanation. I think I understand, might make sense to make some changes so it would be something like MAX_Y and MIN_Y just correspond to the top and bottom of the stage sprite? (for sanity check, the bottom of the world/screen is Y=0 right? or is Y=0 at screen/world center)

It's in the middle of the screen so it's different from 2D to 3D, I also forget about it all the time.
In doubt I just check this https://bevy-cheatbook.github.io/features/coords.html.

[odecay]

Ah okay helpful explanation. I think I understand, might make sense to make some changes so it would be something like MAX_Y and MIN_Y just correspond to the top and bottom of the stage sprite? (for sanity check, the bottom of the world/screen is Y=0 right? or is Y=0 at screen/world center)

It's in the middle of the screen so it's different from 2D to 3D, I also forget about it all the time. In doubt I just check this https://bevy-cheatbook.github.io/features/coords.html.

Gotcha, I checked cheatbook earlier but I couldn't remember where that section was 👍

[edgarssilva]

I left a quick note, also looks good to me.

[odecay]

Alright I'm calling this good for now, We might want to revisit some of the decisions made here in future as we continue to consider #17

[odecay]

I did notice a bug unrelated to these changes which occurs if any player/enemy is allowed to walk up past a certain y height.
The characters sprite becomes covered by the parallax background layers. This currently happens with the boss if he moves near the top of the walkable stage and then performs the jump for his smash attack. This can be reproduced on previous commits as well by extending the max Y value and moving the player upwards.

[odecay]

bors merge

[bors]

Build succeeded:

• Check Rust formatting
• Clippy correctness checks (wasm32-unknown-unknown, web-target)
• Clippy correctness checks (x86_64-unknown-linux-gnu, target)