# Horizontal / vertical flip for shapes rotated 45 degrees

First let me start off by saying that I know how to make the shapes flip properly - the problem is with what the user sees during the flip process (I will be dealing with just the “flip horizontally…” function in this scenario, but it will also apply to the “flip vertically…” function) Referring to this graphic, I will explain (probably in too much detail):

Item 1 is the shape in question. It can be rotated in 45 degree increments in either direction - no problem there. If the shape’s angle is zero or a multiple of 90 degrees and “flip horizontally shape: yes” is invoked, everything works fine (item 2).
However, when the shape’s angle is at 45 degrees (item 3) and “flip horizontally shape: yes” is invoked, I run into an issue (NOT Gdevelop’s fault - just how the flip horizontally function works). What I want to achieve is what you see in item 4. What you actually get is what you see in item 5. It turns out that to properly flip a shape at a 45 degree angle, you need to add (or subtract) 90 degrees from the shape’s angle.

This is where the problem occurs.
During the flip and angle change, for the briefest instance of time, the shape flickers through item 6 before coming to rest at item 4. I’ve tried setting the opacity of the shape to 0 before the flip / angle change, then setting the opacity back to 255, but that didn’t help. I’ve made the code as tight as I possibly could, but I still get that flicker. I’ve attached the relevant section of the extension below - I would appreciate any advice.

Thanks,
Art.

Note about temp_fliprequested: This was implemented for shapes at 90 and 270 degrees. If a shape is at 90 degrees and “flip horizontally shape: yes” is invoked, the user will see the shape flip vertically on the screen. To get around this issue, I test for the shape angle = 90 or 270 and invoke opposite flip function.
A Horizontal flips request is -1, a Vertical flip request is +1. If the shape angle = 90 or 270, I multiply temp_fliprequested * -1 and the user sees the expected result.

I made a sample project to try and understand your flicker/ghost issue, but haven’t been able.
Either I’m missing something, either you have a conflict with one of your events.
Can you take a look and add what’s missing?

@Gruk - I looked at your example and it wasn’t correct. I extracted the rotate and flip extensions from my project along with one shape and the control buttons and have placed the .zip file in Easyupload here:
testFlipRotate.zip
When I was creating the test project, I wasn’t having the “blinking” issue until I change the hit boxes from the default, shared by all animations to custom by animation. I tried adding another animation using the default hit box setting and switching to that animation before the flip, but it didn’t help. I also tried hiding the shape at the start of the flip extension and showing it again at the end of the extension - that also didn’t help.

Thanks for taking a look at this,
Art.

idk your entire setup, but using an animation with frames for each angle and set to frame action could avoid the ficker.

The link is protected by a password, is it part of the game?

Sorry - used “gdevelop” as password.

@Slash - I thought about that option , but for a different reason (was considering giving the pieces a glass-like finish). Unfortunately, that would have caused other issues. As it is, each piece has 5 states: normal, selected(piece clicked on), overlapping(piece is partly or fully on top of another piece), overlapping and selected, and test(used to determine if the chosen goal has been accomplished). For these 5 states, there are 3 different hit box configurations. If I were to add in a rotational aspect (each piece can be rotated in 45 degree increments) it would multiply the number of graphics by 40 per piece. I’m working on one of the smaller puzzles with 16 pieces, so it would require 640 graphics for the pieces. That’s a lot of graphics to create, load and configure. If there is no other choice, I will go that route, but I would prefer GDevelop to handle the “heavy lifting”.
Art.