Boss can jump "behind" background layers
odecay opened this issue · comments
If any character moves up past a certain Y value their sprite becomes covered by the parallax background sprites. This is currently possible during the jumping portion of the boss' smash attack if it starts from near the upper boundary of the walkable stage.
Also reproducible with player characters by changing consts::MAX_Y to be a higher value, then walking upward.
Originally posted by @odecay in #241 (comment)
example with player, note the z value and background sprite covering fishy
We could change the base z value of fighters as well as the parallax layers in the ParallaxResource. I thought we add some constants for that but seems not so we could create some.
Edit: Actually the z values of the fighters are already in asset files of the levels so we could change the z there.
Would it not just get overwritten by the ysort system? I tried adding an offset in ysort system but it didn't seem to help
I also tried offsetting the parallax layers in the level file but it didn't behave as expected
Would it not just get overwritten by the ysort system? I tried adding an offset in ysort system but it didn't seem to help
The y-sorting should only add to the existing z value. Actually it isn't so we could do that.
Should just work by changing the = to += in https://github.com/fishfolks/punchy/blob/dfadfce439aa4d14ba09c7a442c28db52d17d608/src/camera.rs#L36
That would be compoundingly adding the y to the z every frame though
That would be compoundingly adding the y to the z every frame though
Ho right :P in my mind I thought we were adding then subtracting before and after render but I never actually ended up implementing it like that.
I'll try some stuff out tomorrow and then submit something.
Im going to just add a set value for now so we can get a release out. I tried and it works with 300. But going to leave this open so we can come back to it.
Actually, I think you should keep the Never mind you kept it to 0., ok then I'll check it out tomorrow.ysort.0 because it differs on the sprite height, but keep the 300.
Actually, I think you should keep theNever mind you kept it to 0., ok then I'll check it out tomorrow.ysort.0because it differs on the sprite height, but keep the 300.
yeah we arent using the Ysort offset right now, all fighters are initialized with 0. offset since the foot position stuff takes care of sortof what the ysort offset was doing before, but I think it will come in handy if we get to virtual Z for jumping so I think it makes sense to leave it. I could keep the ysort in that calculation AND add the offset which would probably be more correct, but I'm going to leave it the way it is with the intent of removing the new offset from there entirely or moving it to a const if we decide there is not a better way to deal with it.
edit: on second thought I added the ysort back to the calculation in ysort system, and clarified some comments for when we take another look at it #245