Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect behaviour when sliding windows #90

Closed
Morgerion opened this issue Mar 26, 2023 · 4 comments
Closed

Incorrect behaviour when sliding windows #90

Morgerion opened this issue Mar 26, 2023 · 4 comments

Comments

@Morgerion
Copy link

I want to make sliding windows like they are done in Royal Match, Toon Blast, Squad Alpha and other top-tier projects.
I tried this a few years ago on some custom version of the Monarch (2.15.0?), and it worked:

gui_slide.mp4

...
I have now switched that draft project to a fresh version of Monarch (3.7.0). And it's all broken!

gui_slide_bad.mp4

Between the two versions of the project only the Monarch's version has changed.
Here is an archive of that version of Monarch that works correctly (this is a custom version based on 2.15.0):
monarch__.zip
Hopefully this will help make "sliding windows support" available in the new Monarch.

@britzl
Copy link
Owner

britzl commented Mar 28, 2023

It does indeed look a bit strange. I created a sliding window example myself, and the only thing I notice is that there is a bit of a gap between the window that slides out and the one that slides in:

slidingwindow.mov

https://github.com/britzl/monarch/tree/master/example/slidingwindow

@Morgerion
Copy link
Author

It's not a gap.
If you set a long sliding time for the windows, you can see that the second window does not start sliding until the first window has finished sliding.
And we need both windows to start sliding at the same time.

@britzl
Copy link
Owner

britzl commented Mar 29, 2023

If you set a long sliding time for the windows, you can see that the second window does not start sliding until the first window has finished sliding.

This is actually incorrect. I found that the default transitions positioned the node that was transitioning in on the screen too far out (twice the window width):

fe83412

With the correct offset it works a expected:

Screen.Recording.2023-03-29.at.09.21.54.mov

@Morgerion
Copy link
Author

Thank you, the solution turned out to be completely workable!
The issue can be closed.

@britzl britzl closed this as completed Mar 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants