Platform character glitching on change of origin when using flip

[CustomLenny]

Describe the bug

When using animations + changing points + flipping object on a platform character, characters position bugs out moving right and jumping in various combinations

See example and: walk left, stand still, jump = normal behavoiur walk right, stand still, jump = (at most times) glitch in air correcting position

To Reproduce

See included example IssueCenterPoint.zip

[CustomLenny]

Addition* -- Remove the animation action in each of the 5 scene events to see character then respond correctly when moving right and then jumping.

[Bouh]

When you keep only these events problem is still here :

Here what happen 1frame/sc, 13frames

[4ian]

First thanks for the report and including the example game - this was very useful and I was able to identify the problem in 5 minutes! :)

There is indeed a bug where set the position of a flipped Sprite object was not accurate in the case of a flipped sprite that has a custom center and/or origin and/or scaled.

This is fixed for next version - I've checked that your example is now working properly (the fix is really simple, see it here it's only 2 lines of code). Hopefully adding type checking to the source code of the game engine will catch mistakes like this in the future.

It was a fairly obvious bug but I did not see it because I've always been doing platformer games with sprites having a center point that is on the center.

[CustomLenny]

This problem wasn't actually fixed correctly. Before the character would flip around either the origin or centre (unsure which one), and then jolt into the wrong place. As in the flip was correct, however the jolt after was incorrect. This 'fix' actually removed the flips correct centre and avoids the jolt just by flipping into the incorrect position. So now, neither the centre nor the origin mean anything in terms of flipping.

[CustomLenny]

It is the centre point that is the issue. So the patch has made the centre point useless.

[4ian]

Can you include another sample game showing the problem? I'm not sure to understand what is wrong.

[CustomLenny]

The old sample game still acts as the sample. So before (when it was glitching) say I put the centre on the far left of the character, the character would flip around the centre, meaning the right of the character would then line where the left was, this was the correct behavior however then it would glitch into a position that was like the centre was still in the centre of the character. Now (after the patch) regardless of where the centre is, the character still flips around the centre of the entire object, rendering the centre point useless, at least for flipping.

[CustomLenny]

IssueCenterPointContd.zip If you open this in Beta 79 you will see that they flip around the centre point. However in Beta 80 where the glitch was fixed they now flip around the centre of the object.

[zatsme]

It looks perfect to me but then I'm expecting the sprite to be flipped, not the object. I think Lenny is thinking the object should flip which is understandable when the action is 'flip the object' and the parameter is also an object!

IMO it's working perfect but the text should read, 'flip the objects sprite'

Zat.

[CustomLenny]

Zat, did you open in beta 79, because the flip had never been to flip the sprite, the flip always flipped the object around the centre up until the patch that was fixing a movement glitch. If you have a rotate parameter would you expect it to ignore the centre marker too. Its not that I think the object should be flipped, its that I know the object should be flipped, as that has always been the characteristic of flip up until this patch.

[zatsme]

I did open in 79 and prefer the way it works in 80, but that's just my opinion, never really used this function in GD but I've only ever flipped sprites before (in other engines) so it's what I expected to happen. But everyone has different ideas 😄

[CustomLenny]

Great so you did see that the glitch patch broke the flip. Other engines don't self define a centre point. If you want it to flip the object on itself you leave the centre set to auto, pretty simple. Gdevelop flips the object on flip and here's how one can know; a point say defined as X placed on the left hand side of the object will flip to the right on using flip. So you can define a point for a gun at the tip of the gun and still have it on the tip when flipped otherwise it will come out of his back.

The preference of the way something looks is defined by how you design the game, its not about looks this is entirely about function and underlying code.

[4ian]

I think this all comes down to some lack of documentation around the way things are meant to work, in GD at least.

The theory is:

• When an object is set to be at a position X;Y, this is the origin point that should be at this point (when sprite is not rotated, not rescaled, not flipped). This position X;Y won't change, whatever the rotation/scale is - because by definition it IS the position of the object.
• When an object is rotating, the point that is not rotated is called in GDevelop the "center" (called the "center", "pivot", "anchor").
• When an object is flipped, there are no points involved: all sprites are always flipped in the sense that they are displayed at the same position than before, but flipped. In other words, the "center" of the flipping is the center of the sprite (whatever the "center" point is). This is akin to what would happen if you flipped the sprite in photoshop or an image editor.
  • Points are all "flipped" too. So that if a point was on the sword of a character, it will be on the sword after the sprite is flipped.
  • This also includes the "center" point. Meaning that if a sprite is rotated around and flipped, it will continue to properly rotate around the "center". This is important: the "center" is always the point around which the object is rotating.
• When an object is rescaled or rotated, the point are also "rescaled" or "rotated".
  • So that if a point was on the sword of a character, it will be on the sword after the sprite is rescaled or rotated.

See this example that I've made: Sprite flipping and resizing.zip

You can see that some invariants are there:

• Even if the sprites are rescaled/flipped/rotated, the points are always following the image properly (the point at the top of the sword will always be at the top of the sword no matter what transformation you do).
• X;Y position is not moving
• Sprites are rotating around the center point, even if flipped.

This being said, there might be a flaw in this design or something missing. I think the assumption I made was mainly that the center point is only for rotation. Flipping is considered "just" as reversing the image (including the points) inplace, but this does not involve the center.

We might want to add this in a wiki page?

[CustomLenny]

Two problems though; 1) the main one being though that wasn't the original functionality before the glitch patch, the original functionality was that it would flip around the centre point marker

When an object is flipped, there are no points involved

There must've been in before this patch

2) when rotating and then flipping, the centre won't remain in the same spot if the centre marker is not in the centre of the object

The main problem arises when you have a character say like Pinocchio, you wouldn't want him flipping in the centre.

When an object is rescaled or rotated, the point are also "rescaled" or "rotated".

Is the object rescaled using the centre of the object or the defined centre point?

---

It literally flipped around the centre marker previously, and it worked perfectly fine until extra animations were added, the problem was that upon adding animations it would cause it to glitch position from the point of being flipped around the centre marker to being where it would be if the image was flipped.

[zatsme]

This is Pinocchio flipping in the center and the object being offset when turning left or right, this is how I've always done this as it's a simple solution 😄

[4ian]

The main problem arises when you have a character say like Pinocchio, you wouldn't want him flipping in the centre.

Yes that's indeed a good example. I think the proper answer here would be to add a "flip center" - not sure though how much extra calculations this implies in the game engine.

There must've been in before this patch

Yeah flipping was incorrectly done previously to this patch. Now it's "correct" in regards to what I defined earlier - you can consider the "flip center" to be always in the center of the sprite and this is not customisable for now.

We could use the same point for the "flip center" and the rotation "center", I wonder if there would be a reason to differentiate them (other than the fact that for backward compatibility, i.e: not to affect the behavior of existing games, they should be different, with the default being both at the center of the sprite).

[CustomLenny]

other than the fact that for backward compatibility, i.e: not to affect the behavior of existing games, they should be different, with the default being both at the center of the sprite

The thing is, backwards compatibility wise would be to flip around the centre point, as that was the actual behaviour up until beta 80. The behaviour for beta 79 and before is that it would flip around the centre point, when I added the extra animations that is when I discovered the position glitch bug when it switches between animations. The patch that fixed the bug (that was borking my two games) now has broken my two games.

Anybody who made a game pre beta 80 the flipping for them would've been around the centre point.

And if those like zatsme are leaving it in the centre and calculating the offset then it wouldn't affect them anyway.

---

In addition to that, if flipping was actually meant to work on the sprite then the correct behaviour for rotating and then flipping would have to work like this:

---

Ultimately for me personally, I need to know whether the original (and correct :P ) functionality will be restored so I can continue on my two games, or if I should just cut my losses on the time spent in gdevelop and switch to something else.

[CustomLenny]

In addition to what I just said above I want to present this example.

If you try this in beta 79 there is the position glitch issue still present, so to somewhat circumvent this hold down Up continuously and steer with left and right, then compare to beta 80.

ShipRotateFlip.zip

As I say, the changing of flip not being applied to the defined centre is what breaks backwards compatibility.

[4ian]

Thanks for the example, can you make side by side comparison of the proper/wrong positioning in the ship in your latest example? (Sorry but I have little time and can't see the difference when trying with beta 79 and 80, would be helpful to have exact screenshot showing the difference)

[zatsme]

I think it makes sense to have both, should we have both object and sprite functions?

flip object Rotate object Etc...

And also same for sprite? 🤔

[4ian]

In the example of the spaceship, it's disturbing to see the spaceship "jumping" when being flipped, because the flipping is made around the center, and then the rotation is made around this flipped center.

This being said, I don't see the difference in this case with beta 79, a screenshot would make things quicker for me to see :)

EDIT: I know I'm a pain asking of example and screenshot, but this cut the investigation time for me from hours to minutes. EDIT2: I have also rechecked your very first example showing the bug in the platformer, and beta 80 is properly showing the character compared to beta 79 where there is a jumping glitch. This seems unrelated to the spaceship example though - which seems more related to an issue of applying flipping first THEN the rotation leading to surprising result... but I still fail to see how fixing the first issue created more down the road (because it was clearly wrong in beta 79).

[CustomLenny]

EDIT: I know I'm a pain asking of example and screenshot, but this cut the investigation time for me from hours to minutes.

this is no issue, happy to provide any examples or diagrams necessary

You'll have to ignore the glitch in the beta 79 as thats the original moving issue of this original post. But on traveling in a straight line and rotating with arrow keys having an off centre rotation point means that in beta 80 the position at which the main part of the ship will be will not be in the same continuous point.

I think it makes sense to have both, should we have both object and sprite functions?

atm (imo), the way the rotate seems to work is based on object but the way the flip works is half based on object yet half based on sprite. half of it is relative and the other half is absolute (or something like that) (ps zatsme, i liked your quick Pinocchio adaption :P )

[CustomLenny]

EDIT2: I have also rechecked your very first example showing the bug in the platformer, and beta 80 is properly showing the character compared to beta 79 where there is a jumping glitch. This seems unrelated to the spaceship example though - which seems more related to an issue of applying flipping first THEN the rotation leading to surprising result... but I still fail to see how fixing the first issue created more down the road (because it was clearly wrong in beta 79).

So the original issue in beta 79, if you remove the 2 animations and have just the one image there is no glitch when jumping, however the flipping point is around the centre, which it always was. The glitch happens when more than one animation is applied and there is a switch in the animation. Otherwise with just 1 sprite the object would flip around the centre point. My sprites are not centred over the middle of the image, they are more like Pinocchio. So when the jumping glitch got fixed and removed the original behaivour of flipping around the centre it threw off all my objects when they flip.

edit: quick summary; The Pinocchio example zatsme provided is actually how things functioned before this patch, and the original bug in this post would occur once extra animations were put into an object and switched between

[zatsme]

To 'fix' your issue, you can always change your sprites so that the spaceship center is actually the centre of the sprite in all cases which is what I've always done as its easier to code 🤔

[4ian]

@CustomLenny Just to confirm, your GIF was done with "ShipRotateFlip.zip"? I may have not been completely awake when checking this morning, but I had the impression of having the behavior of beta 80 in both beta 80 and 79.

What is sure is that beta 80 fixed an actual issue where the X and Y position of the rendered image on screen was not correct when updating the position of a flipped object (it was correct only when image was changing in an animation). I wonder if beta 79 looks "better" because of the bug and so what you now need is a way to change the flipping center point (or to set a new convention that flipping center will be the same as the center point) - so that there is no glitch AND proper positioning.

[CustomLenny]

so that there is no glitch AND proper positioning.

this :P

Just to confirm, your GIF was done with "ShipRotateFlip.zip"

Yes, both sides done using the exact same file. Which even minus rotation on that ship example, all the time before beta 80 the flipping was done based on the centre point, but that is what your saying was the bug or what was causing the bug.

[4ian]

So looking again at the code, in version beta 79 before the bug fix, two lines that were doing the positioning of the flipped sprite were not applied. When looking at these lines, not calling them is equivalent to considering that the flipping position is equal to the object "center" point.

This seem to confirm that we had a "double issue" there: both a positioning issue in certain case (the "jumping" animation glitch) (which is fixed in beta 80) AND the fact that the flipping is done relative to the center of the image, leading to surprising results when sprite is flipped and rotated with a center point that is not the center of the image.

I have yet to confirm that's the case, but I see two possibilities:

1. Either add another point that would be the flipping center.
2. Or always consider the flipping to be done on the center point.

Solution 2 seems better because it's simpler, it would actually be removing some complexity in the code, improving slightly performance and would (hopefully!) be "what you would expect of flipping/rescaling/rotating something". In this regards, the center point would be "the point that is never moving when the sprite is transformed". Solution 1 seems more complex and I'm not even sure anyone would need this. If that's the case, you better offset the sprite by yourself in events.

I'll take a look at solution 2, I hope this can work and simplify things. If that works, I'll make a button to opt-in to the "new", "fixed" rendering for existing objects. New objects will automatically use this.

[Wend1go]

I have to admin that I couldn't completely follow the discussion, so this suggestion might be completely off.

How about adding a "Point" parameter to the "Flip Object horizontally/vertically" action that takes the "Centre" point as a default value? That way we could keep backward compatibility and make it easier to flip an uneven sprite (like a door that could open to both sides when using a point at (0/X).

[4ian]

So this would be a bit like solution "1: add another point that would be the flipping center", with the addition of an extra parameter to allow changing on the fly the point. At this point (see the pun?), I would prefer having an action to change a point position using the events - which could be done separately from this :) It would actually even work with solution 2 (as you could move the "center" point if needed) - so I think it's another feature request. Though might be not very difficult to do - might be worth giving it a try if you want to (I can't remember though if all object instances are storing their own points or if they are sharing them in memory).

For now I'm still more leaning toward using the center point for all transformations as this might be more performant and less bug prone (have still to confirm it works though!).

[CustomLenny]

Solution 2 sounds good, basically what was happening pre beta 80. And it shouldn't affect people who defined their own offset as they would've left the centre point in the centre regardless. Maybe zatsme can comment on if they change their centre point from 'auto' as they are someone who defines their offset in code.

[4ian]

I've started updates in https://github.com/4ian/GDevelop/commit/567be06f4cb8f29c30da9e55c56dcf3ab5d38775 but need more time to make sure that this is the right thing and not badly impacting performance.

Backward compatibility will still be needed because even not a lot of people may have used a custom center together with flipping, it's still changing the behavior in this case.

[4ian]

I'm almost thinking of ditching at some point the centre and origin distinction and just keep a unique point for everything. This is what is done by Pixi.js/Cocos2d-JS. For now I'll keep both because I don't want to do to much changes.

[CustomLenny]

I'm almost thinking of ditching at some point the centre and origin distinction and just keep a unique point for everything. This is what is done by Pixi.js/Cocos2d-JS.

things usually do rotate around the origin but things dont usually flip around the origin, but also, when something is rotated around an origin and then flipped it's flipped globally and not locally relative to the object

[zatsme]

Maybe zatsme can comment on if they change their centre point from 'auto' as they are someone who defines their offset in code.

Every engine has its own quirks and ways of working, I just work with whats available and code around quirks 😊

I've always made sprites the correct size, so that the center of the sprite is where I want it, changing the sprite is easier than coding, and faster.

[4ian]

Can you all try the GDevelop version that I linked here: https://github.com/4ian/GDevelop/pull/1249?

I would like to know if:

• that fixes your issue @CustomLenny
• @zatsme, @Wend1go, @Bouh you see any change in the positioning of sprites in your games (should only happen if you use a non default center with flipping - and in which case you should not need events to fix anything)

[Bouh]

I don't use this action, but i've added an announce about PR #1249 on Discord

[4ian]

Sounds like a good idea, thanks @Bouh!

[CustomLenny]

As far as flipping goes, this looks like it's all working for me and looks smooth. However it's revealing some other bugs that when I went back to check other versions they were still there as well, even when flipping in the centre. I do find that things with defined collision boxes don't actually collide properly, and things with offset centres can act in the same way when going in one direction yet not the other.

Also this was showing up just in case you didn't know.

[Silver-Streak]

I'm going through older issues to bring attention to them or close them out. The final post from @CustomLenny seems to relate to #2379, which has since been resolved.

Are you still seeing this issue?

I will close this out upon confirmation that this has been resolved, or if no response is received 30 days from this post.

[CustomLenny]

I've moved away from gdevelop as this whole problem was driving me a bit mad. I'll have a poke around in gdevelop in the future however how this works won't affect me as I'll be starting with a clean project. Thanks for checking.

[Silver-Streak]

Closing due to no updates and I cannot reproduce this issue currently. If it is reproducible feel free to reopen.