Jump to content

Purpose of custom Loader instances


Aroxis
 Share

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!

Link to comment
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 :)

Link to comment
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? 

Link to comment
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?

Link to comment
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

Link to comment
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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...