openfl dev compatibility fixes #15
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This isn't a real PR, it's used for swfs in Funkin, I do recommend applying similar fixes to swf, but that should be done by someone more familiar with the lib |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I tried out openfl-player and found some issues with runtime Swf parsing and swflite. these were the changes needed to get the project working.
I couldn't get any swfs to render on html5, except with swflite. the only swf that worked on html5 with swflite was badgerbadger, and my own custom swf. @barisyild mentioned they couldn't get as2 swfs to work with swflite. Any leads on why html5 doesn't work without swflite would be greatly appreciated.
I'm not sure this is the best way to handle, things. Specifically MovieClip.setChildField and SpriteSymbol.__setConstructor. The use of
__constructorhere seems odd and dangerous, to begin with. why not just call__constructoron the created movieclip in__createObject?