Fixes to make the preloader work on HTML5 #1846
Conversation
…into html5preloader
… onLoad parameter of the constructor.
…ey can be skipped as long as the onLoad argument is provided last. This removes at least _some_ of the clutter.
… had assumed this was necessary (in order to force the __dirty flag to false), but it now seems this isn't the case.
…mapdata. This allows for much cleaner code, without even requiring any conditional compilation in child preloaders.
| * @param onLoad Executed once the bitmap data is finished loading in HTML5, and immediately in Flash. The new BitmapData instance is passed as an argument. | ||
| * @return The BitmapData instance that was created. | ||
| */ | ||
| private function loadBitmapData(bitmapDataClass:Class<BitmapData>, onLoad:BitmapData->Void):BitmapData |
There was a problem hiding this comment.
This function doesn't even seem to be used?
There was a problem hiding this comment.
It isn't used in the default preloader, but I included it for the benefit of those writing custom preloaders, in case anyone wants to load an embedded bitmapdata without immediately creating a Bitmap object using it.
There was a problem hiding this comment.
Either way, the implementation is completely redundant. This method should be used in the preloader, wrapping the BitmapData in a Bitmap can easily be done there.
Also not sure this is really the right place for a utility method like this...
There was a problem hiding this comment.
FlxAssets would probably be a better place for it (as getEmbeddedBitmapData() maybe)?
There was a problem hiding this comment.
Although "embedded" is a bit ambigious, there's also the option of embedding assets included via the project.xml...
There was a problem hiding this comment.
That's correct. We already do that in the debugger (although all buttons are 11x11, so not that hard to get right), so at least it's a consistent workaround... And getting rid of the callback awkwardness counts for something too I guess?
There was a problem hiding this comment.
Yeah, the callback system is pretty messy... But remember that it's not only about the default FlxPreloader, many people write custom preloaders. And having to manually supply all images' size (and keep it up to date whenever I switch images!) feels, at least to me, like it'd been even more awkward than the callback system.
But I dunno... I guess there isn't any good solution.
There was a problem hiding this comment.
The good solution would be a fix at OpenFL level.
There was a problem hiding this comment.
True. Although it's not obvious what a good solution on that level would be, either.
There was a problem hiding this comment.
Lars' solution seemed quite sensible to me:
On export, have the tools
inspect all the bitmapdata objects for size and write that data out, so that we can
have an additional Assets.getSize() command that gives you the width/height
of a bitmapdata without actually loading it.
|
Do you know what's responsible for the textfield being resized like this after a few frames? |
|
No, I'm not sure what is causing that. Well, it's obviously because there's a delay until it starts using the correct font, but I don't know why that is. My guess is it's similar to the bitmap loading issues, i.e. it takes a while until the specified font has actually been loaded... But that's purely a guess. |
|
Are you seeing the same effect / have you looked into possible fixes? |
|
I've seen that effect, yes... But for me, it has always resized so quickly I don't really notice it unless looking for it, and I've never seen it as that big a problem. |
…ad argument required.
|
Thanks for your contribution! :) I merged the changes manually in 00c0e20 since there were merge conflicts by now. |
closes HaxeFlixel#1846 closes HaxeFlixel#1804 Manual merge of @Nallebeorn's pull request.
This modifies FlxPreloader and FlxBasePreloader to work on the HTML5 target. Because blend modes don't work on html5, the default preloader doesn't look quite as good as in Flash... but it runs. More importantly, FlxBasePreloader works fine, so custom preloaders can be made (which don't use blend modes :))
There are some quirks to be aware of with regard to embedded BitmapData and TextFields with custom fonts (and probably other things I haven't encountered yet) – this is documented to some extent in the comments in FlxPreloader.hx. Unfortunately, it inevitably leads to somewhat messier code, but I've tried to keep it as clean as possible.
Fixes #1804.