About Preloader

[XinRex]

hi,

    I copya Preloader From "Bee" example,like this

class Preloader extends APreloader 

{

private var _preloaderMovieClip:PreloaderMovieClip;

override private function _init():Void {

super._init();

_preloaderMovieClip = new PreloaderMovieClip();

_preloaderMovieClip.progress.stop();

_preloaderMovieClip.x = ( _kernel.factory.width - _preloaderMovieClip.width ) / 2;

_preloaderMovieClip.y = ( _kernel.factory.height - _preloaderMovieClip.height ) / 2;

_context.addChild( _preloaderMovieClip );        //error at this "_context"

}

override private function _updater(p_deltaTime:Int = 0):Void {

super._updater(p_deltaTime);

if ( _preloaderMovieClip != null ) 

{

_preloaderMovieClip.progress.gotoAndStop( Std.int( 100 * progress ) );

}

}

}

my Project named "MG",and Added the arg(<compilerflag name="-swf-lib assets/preloader.swf" />) in MG.xml.

then,the Preloader for flash target can work .but not word for android at compile time.like this:

src/Preloader.hx:19: characters 2-19 : Unknown identifier : _context

Build halted with errors (haxelib.exe).

wo,why?

[Rob Fell]

 

Not all swf related principles translate to OpenFL / Android.  So in this example, the MovieClip (PreloaderMovieClip) which is embedded in the "preloader.swf" -swf-lib is neither available to, nor understood by OpenFL native / android.

 

Instead, for Preloaders with OpenFL follow this advice:

http://www.openfl.org/developer/forums/general-discussion/whats-best-way-replace-preloader/

 

General advice:

 

awe6 in swf-template-mode is a versatile framework + preloader + asset system. When used in conjunction with OpenFL it becomes "just a framework", and OpenFL provides the preloader + asset system.  Given that NME / OpenFL changes fairly often, and lots of new work is going into their asset system, you may find more up to date advice on their forums.

 

My workflow is this:

1) Create game for Swf target.  Consider each dependency's limitation on other targets (e.g. favor a Haxe lib, over a Swc lib).

2) Port game to other targets.  OpenFL is one such port.  AIR is another.  Rewriting natively might be another.  awe6 helps porting by separating concerns.

 

I find porting a "finished" game considerably faster than developing concurrently via OpenFL because:

1) OpenFL has some inconsistencies between its backends so testing requires runtime scrutiny
2) The OpenFL buildtool is very clever but introduces extra dependencies and an additional compilation delay

My focus is swf & html5, and I am always impressed when making a final port to OpenFL (html5 especially), but I would rarely begin there.  Good Android advice may likely be different.