• Content Count

  • Joined

  • Last visited

  1. 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 =; loader.add(childObject.url, childObject.url, { parentResource: resource }); }); This works because we specified the resource as a parent to the child.
  2. So being able to instantiate custom Loaders has no real purpose over just using the default Loader at all?
  3. #2 renders just the Sprite while #1 renders both the Container and the Sprite, so it's the other way around, right? But what I gather is that both ways are fine because they can handle much more than the usual use case. Thanks!
  4. Hello! I was wondering if `PIXI.Containers` have any associated performance overhead. Take the following examples: Example #1: Extending Container: class SpriteTile extends PIXI.Container { constructor(resource) { super(); // Create a sprite and add it to children const sprite = new PIXI.Sprite.fromImage(resource); this.addChild(sprite); } } Example #2: Extending Sprite directly: class SpriteTile extends PIXI.Sprite { constructor(resource) { super(resource); } } Both examples achieve the same thing. Example #1, while seemingly more obscure, keeps a certain level of extensibility by having the freedom of a Container. Example #2 is much more direct but is now also limited to the functionality of a simple Sprite. My question being; is there any (notable?) performance benefit over choosing example #2 over #1 in the use cases as shown above? Thanks in advance!
  5. 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!