-
-
Notifications
You must be signed in to change notification settings - Fork 844
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
core: Respect ratio field for non-morph shapes (fix #1291) #1305
Conversation
There are some issues where things remain on screen while they shouldn't:
Other issues:
|
Thx for testing! Could you try again with the latest changes? |
Hmm, I'm still observing the same issues (is it because the PR seems to miss a piece of code from commit 04e3f1ecea9572801a92ac6596134fa5a174b5ba? I'm not seeing the |
Whoops, you're right, I futzed up a rebase. Should be okay now. |
Almost all of the games above work as intended now! 👍 Only Zed still has issues with transitions (for the audio stuff on Luigi's Day, I will open a bug report). I've also tested other files, unfortunately it turns out some of the games by Ferry Halim have issues: Starry Night (http://www.ferryhalim.com/orisinal/g3/starry.htm) Critical Zone (http://www.ferryhalim.com/orisinal/g2/criticalzone.htm) The Bottom of the Sea (http://www.ferryhalim.com/orisinal/g3/sea.htm) |
Thx for the testing! Upon thinking about this some more, I think better would be to change |
Closing in favor of #5431. |
This changes the logic for rewind-gotos to respect the ratio field inside the PlaceObject tags. See #1291 for a full description.
Previously we would manually keep track of the placement frame for a display object whenever it was instantiated. A rewind would immediately remove all objects that were created after the target frame (because they should not exist on that frame). However, now we need to inspect the ratio field of the final PlaceObject tag to decide whether to remove an object; so now we defer the decision of whether to remove an object until after we churn through all the frames.
Still needs some more research+testing to verify this doesn't regress anything. I need to add a test case to verify the new behavior. My initial tests indicate this does fix #1060, which makes sense because this SWF is made by a 3rd party tool.