Accessing swf assets from a preloader

#1

In my project.xml I’ve got the following:

<app preloader="Preloader" />
<library path="swf/assets.swf" id="assets" />
<library path="swf/loader.swf" id="loader" preload="true" />

The first thing my Preloader class is try and get a movieclip from the library named “loader”, but is immediately met with an error saying it doesn’t exist.
Assets.getLibrary(“loader”) works, but I cannot get any data from it.

It was my understanding preload=“true” in the library attributes also meant that the swf was available during the preloader, but I suspect not.

Is there a work around for this?

EDIT:

Calling Assets.loadLibrary(“loader”) and waiting for it to complete works.
I’m also curious though, when I load the app in html5 I noticed the main js file is almost 2MB big. This needs to load entirely first before my preloader even shows.
Is there any way to improve this?

And besides throttling my connection in chrome for the HTML5 target, what other nifty ways are there for testing a preloader in OpenFl?

#2

The idea of preloader is to work before everything else is loaded, so you can, let’s say, animate the process of loading.

preload="true" means OpenFL loads your swf automatically, so you don’t need to do it manually.

#3

Lime supports -Dsimulate_preloader and -Dsimulate_preloader=5000 (or however many MS you want it to delay)

The simulate preload progress should fake the progress values in order to better test development of a custom preloader :slight_smile:

#4

That’s exactly what I was looking for, thanks again! :slight_smile:
However I’m still left wondering about how to handle that fat pre-preload for the main app js.
Is there an inbuilt minify process to shave a few pounds off the beast? Or should I setup npm and do it myself?
Also, it just occurred to me that it would be good to have a default pre-preloader in the html template, while the js loads.
I don’t know about you but I always get nervous when I see a large white rectangle for too long. Looks frightening.
I know it doesn’t require much work to implement it manually, but evenso I would appreciate having this as an inbuilt feature.

#5

Have you tried -final?

openfl test html5 -final

This uses minification and dead-code elimination to reduce the JS output size. This can result in a JS size of around 200 or so KB unzipped, but most servers Gzip text files automatically, resulting in around 38KB worth of actual download size for a client, which probably isn’t too bad?

#6

Tah. That’ll do nicely :slight_smile:

1 Like