Sign in to follow this  
Aroxis

Purpose of custom Loader instances

Recommended Posts

Hello!

As a relatively new Pixi.js user I have been experimenting with loaders and had a few questions mainly regarding the ability to instantiate custom Loader instances. Pixi provides a default Loader instance at `PIXI.loader` but also provides the ability to instantiate new instances using `new PIXI.loaders.Loader()`. 

I assume that one of these benefits these custom instances bring is being able to assign different middleware to different instances, essentially creating multiple Loaders with each their own purpose. To give an example, I have been working with '.tmx' and '.tsx' files (from Tiled). For both of these type of files I have created middleware to parse them accordingly. By creating two different loaders and assigning the custom middleware to be used respectively:

const tmxParserMiddleware = require('./tmxParser');
const tsxParserMiddleware = require('./tsxParser');

// Instantiate loaders
const tmxLoader = new PIXI.loaders.Loader();
const tsxLoader = new PIXI.loaders.Loader();

// Assign custom middleware respectively
tmxLoader.use(tmxParserMiddleware);
tsxLoader.use(tsxParserMiddleware);

// Load files with their respective loader
tmxLoader.load('<tmx_file>');
tsxLoader.load('<tsx_file>');

This would promote better separation of concerns over the possibility of simply doing this:

const tmxParserMiddleware = require('./tmxParser');
const tsxParserMiddleware = require('./tsxParser');

// Reference default loader
const loader = PIXI.loader;

// Assign custom middleware
loader.use(tmxParserMiddleware);
loader.use(tsxParserMiddleware);

// Load files 
loader.load('<tmx_file>');
loader.load('<tsx_file>');

While both of these examples would work, am I right to assume that the first example has better performance (by not iterating over the unrelated middleware that targets a different filetype) and should in general be used as best practice? The official Loader documentation does mention the availability of the custom loader instance but does not further explain the benefit or best practice behind them. I've also been unable to find any more information regarding this using Google.

Thanks in advance!

Share this post


Link to post
Share on other sites

Over-thinking. That's one extra function call and one extra "if" we are talking about, the parsing takes significantly more resources than that if.

So far i didnt see any cases when it was necessary to rewrite resource-loader or change something regarding its performance.

However I have custom version of it written on typescript, for experiments :)

Share this post


Link to post
Share on other sites
18 minutes ago, ivan.popelyshev said:

Over-thinking. That's one extra function call and one extra "if" we are talking about, the parsing takes significantly more resources than that if.

So being able to instantiate custom Loaders has no real purpose over just using the default Loader at all? 

Share this post


Link to post
Share on other sites

It can be useful to have multiple loaders, as the loader pixi uses will not let you add resources to load whilst it is currently in it's loading process.

So imagine you were were dynamically loading in assets as required in a game, you might set some assets loading, but then you reach another part of the game and want those loaded too. The first loader is in progress and still hasn't finished yet, so you need another one to load this second batch. 

Rather than having all load queues that are equal, perhaps you have a pool of loaders, some are high priority "must load asap" with a high concurrency, and maybe you have a pool of loaders that deal with low priority 'trickle' loading with a concurrency of 1?

Share this post


Link to post
Share on other sites

multi loader are userfull in multiples case.
here a context example where i need manage multi loader for texturePacker,s normal,multiPack and animations.
it's also much easier to manage and debug and this is impportant for big projet.

https://github.com/djmisterjon/PIXI.ProStageEditor/blob/47f284b9419bba509acd0cbc0b3739091c3fc80d/js/core/loaders.js#L175

Share this post


Link to post
Share on other sites
12 hours ago, themoonrat said:

It can be useful to have multiple loaders, as the loader pixi uses will not let you add resources to load whilst it is currently in it's loading process.

As far as I have found this is not entirely true. It does allow recursively loading resources as long as the newly added resources are a child of the parent resource.

// Add object to loader
loader.add(object);

// Load object
loader.load((loader, resources) => {

  // Add child object to loader
  const childObject = resources.data.childObject;
  loader.add(childObject.url, childObject.url, { parentResource: resource });
});

This works because we specified the resource as a parent to the child.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.