Pixi Display

[Ianmh]

Probably a silly question, but how do you import pixi-display in TypeScript? I've fairly new to TypeScript, but this works for Pixi.js. 

import { Application, ApplicationOptions, Container, Graphics, Sprite } from "pixi.js";

But this does not for pixi-display.

import { DisplayGroup } from "pixi-display";

Also is pixi-display the preferred way of sorting or is there another way I should be sorting containers? I basically want to be able to add multiple containers to the view and if you click on one behind another it will come to the front and stay there. 

[ivan.popelyshev]

Please try that one and report which one works for you: https://github.com/pixijs/pixi-display/issues/11 

Personally, I dont know how to do all that stuff in browserify or webpack, its too magic ffor me. I love global namespaces. May be you can show mne how to rebuild the lib to use with others. Or i can port https://github.com/pixijs/pixi-spine approach, we solved it there.

[ivan.popelyshev]

For sorting things inside one container, I prefer simple sort. Just assign z-value to children and do something like "Arrays.sort(container.children, (a,b)=>{return a.z-b.z})", or just bring that children to front somehow (remove and add?).

In that case, implementation with pixi-display takes as much time as simple solution. I wont adverties my lib just because its awesome, its one more dependency that can be evaded if the case is simple. Dependencies are evil.

Sometimes you need to sort THROUGH the tree. That kind of problems require to think a lot and write many lines of code, and that's where pixi-display saves a lot of time.

[mattstyles]

4 hours ago, ivan.popelyshev said:

Personally, I dont know how to do all that stuff in browserify or webpack, its too magic ffor me. I love global namespaces. May be you can show mne how to rebuild the lib to use with others.

Pixi works great with browserify, well, apart from one thing, https://github.com/pixijs/pixi.js/blob/dev/src/index.js#L51, but, I can understand if the vast majority of users expect it to be global even when they are using a module packer.

For extensions/plugins/modules like pixi-display things would get more complicated, you'd need to use some sort of UMD build as it leaks globals like crazy, but more than that you'd have to expose some method of passing in a pixi instance to mutate, and even that would get nasty because you wouldn't want to do that everywhere that you use the extension library, so, yeah, a bit more thought would be needed and possibly lots of changes to support this in a module world, which seems a bit meh when it currently works well for most users.

edit: Actually, thinking about it, presumably browserify/webpack do not work fine when you start adding plugins like pixi-display/spine etc etc as they mutate the global PIXI instance and a module system will always be grabbing the raw pixi object, although, in the case of browserify, this becomes a cached instance so maybe it routes through just fine.

edit edit: I did just check this, due to how browserify caches objects to use adding a plugin like pixi-display works just fine. i.e. the following contains the extra stuff that pixi-display adds:

// main.js

import {Application} from 'pixi.js'
import 'pixi-display'

import show from './showme.js'

show()


// showme.js

import {Container} from 'pixi.js'

export default function show () {
  var c = new Container()
  console.log(c)
} 

There are quite a few caveats here, in your entry file you must import something from pixi.js to create the global PIXI instance, then just make sure your extension is added (i.e. import 'pixi-display') which will mutate the global PIXI instance. Due to how browserify works when you get to `showme.js` and import the container pixi-display has also pulled the rug from under you and mutated this instance also (by ref) so things work out probably how you want.

I can't guarantee other module bundlers will work in the same way though.

[Ianmh]

I'm actually using Browserify. I've tried to wrap my head around webpack on web projects but have failed to so far so I won't be much help. I like Browserify a lot, but I'm still not sure how the module bundling works, although it's on my list of things to learn.

Thanks for the suggestions though, I went for a custom method, here is my code.

this.parent = event.currentTarget.parent; // Current container
this.collection = this.parent.parent.children; // All containers
this.parent.active = true;

this.collection.find((container: any, index: number) => {
    if(container.active) {
        // Move the container to the front.
        this.collection.splice(this.collection.length - 1, 0, this.collection.splice(index, 1)[0]);
        this.parent.active = false;
    }
});

This seems to be working well. I get the parent container because the actual click event is on a sprite converted from a polygon and it's a group of sprites from the polygon shapes. 

Edit: For some reason the code keeps losing it's formatting when I save. 

[mattstyles]

Browserify is fairly easy to understand if you dig in to it, you can take a look at the output, its very minimal. It adds a couple of functions it needs to work and then wraps all of your modules into a function which can be invoked when you want something. So, say, depA.js exports a string, browserify turns this whole file into a function, when invoked it returns the string, then, inside main.js it provides access to the function that defines depA.js so that when the code hits the bit where you import/require it, it runs the function and you have the export (in this case a string). To make commonJS spec it caches the output to save evaluating the file/function each time you want it. Browserify (I think) only handles commonJS, if you're using import/export ESNext syntax then you need something like Babel to turn that into commonJS spec first so that browserify can operate on it. In essense browserify works out your dependency tree and provides methods for accessing it, I'd be surprised if other module bundlers didn't theoretically work to the same model, as it has a representation of the dependency tree stuff like factor-bundle can work against it to calculate common dependencies and provide different bundles (if you want to do that).

Webpack actually does something kind of similar, but I'm less sure on the specifics. I've used webpack a fair amount and, like you, can't say I'm a fan, seems very overly complex for what it does. You can get really clever with build pipelines, but, by doing so you're actually not being clever! Less is more!!

The problem you're facing isn't with module bundlers but with how pixi works. It's kind of a tricky one, because pixi implements adding extensions in a very simple way, which is great. It expects to be a singleton, so a global makes sense. To use in a module world you'd probably want to create a file that specifies pixi and then applies each extension and spits out the pixi singleton. As pixi uses this global this is unnecessary but if you wanted to go down the module route and ignore globals then you could do it this way, this is because commonJS spec doesn't re-evaluate modules which makes exporting singletons trivial if you want to. To eliminate the global pixi would have to stop exporting it and then each extension would have to have some sort of initialisation function that takes a pixi instance to work against, at the moment I think they tend to grab it from the global. I guess, there might be a better way but I wouldn't expect Pixi to do this anytime soon (if at all).

[ivan.popelyshev]

19 minutes ago, mattstyles said:

Browserify is fairly easy to understand if you dig in to it, you can take a look at the output, its very minimal. It adds a couple of functions it needs to work and then wraps all of your modules into a function which can be invoked when you want something.

A couple of words about alternative:

If your editor is vim/sublime/notepad++ then browserify and webpack are helping a lot. But trends in JS world dont mean best solutions!

TS has global/local namespaces and I believe its easier to manage when you work with IDE's.

The old way is certainly better for big projects, while import/export is cool feature that reduces starting threshold and helps community grow.

[Ianmh]

Thanks for all the great info guys. @ivan.popelyshev when you say easier to manage with an IDE, does this mean it can bundle into a single file too? I use Visual Studio Code, but I've only ever seen it build mulitple files.

[mattstyles]

20 hours ago, ivan.popelyshev said:

The old way is certainly better for big projects

Completely disagree, my current project has over 3000 dependent modules from ~50 top-level dependencies (roughly half are development dependencies and will take up more than their fair share of the 3000) along with over 200 source files (this is actually less than half of the whole project), trying to manage this without a module system would be so vastly time consuming to be utterly impractical, I'd say it would be practically impossible.

As I have a well defined statically-analysable dependency tree and a well defined mechanism for specifying dependencies I can introduce tooling for managing this list, deduping it, resolving conflicts, refactoring builds, removing unnecessary top-level includes via destructuring, etc etc the clever things people keep doing with this kind of information is staggering. Not to mention that each of my source files is well self-contained, no surprises, everything is defined in that file (barring references to window).

[ivan.popelyshev]

12 hours ago, Ianmh said:

Thanks for all the great info guys. @ivan.popelyshev when you say easier to manage with an IDE, does this mean it can bundle into a single file too? I use Visual Studio Code, but I've only ever seen it build mulitple files.

{
    "compilerOptions": {
        "outFile": "./local_build/js/app.js",
        "sourceMap": true,
        "inlineSources": true,
        "removeComments": false,
        "target": "es5",
        "lib": [
            "DOM",
            "ES5",
            "ScriptHost",
            "es2015.promise"
        ],
        "moduleResolution": "node",
        "module": "amd",
        "noFallthroughCasesInSwitch": false,
        "noImplicitReturns": true,
        "allowUnreachableCode": true,
        "typeRoots": [
            "typings/",
            "node_modules/@types"
        ]
    },
    "include": [
        "./src/**/*"
    ]
}

My tsconfig.json . single file from a huge number of "*.ts" files.

[Ianmh]

Ah, I did know about this, but I've read it's not a great option as it can lead to errors. Lots of info about it here. 

https://basarat.gitbooks.io/typescript/content/docs/tips/outFile.html

[ivan.popelyshev]

I use grunt-ts plugin which has "ts-ref" mechanism that helps to generate those links. I prefer to control order of files at build stage rather then at runtime: its old "a requires b, b requires a" problem that exists in all languages.

My approach is based on the fact that i often use different language for critical places. It is compatible with Java/Scala/Kotlin, while small modules are kinda big problem if you want to share the code with native app.

[shashank]

I am working with JS (es5)

I want to put zOrder to different sprite and containers. I tried using below code from pixijs example but found PIXI.display is undefined and got error (Cannot read property 'Group' of undefined)

    var greenGroup = new PIXI.display.Group(0, true);
    greenGroup.on('sort', function (sprite) {
        //green bunnies go down
        sprite.zOrder = -sprite.y;
    });

Is there any extra file i need to include in index with pixi library?

[shashank]

I am working with JS (es5)

I want to put zOrder to different sprite and containers. I tried using below code from pixijs example but found PIXI.display is undefined and got error (Cannot read property 'Group' of undefined)

var greenGroup = new PIXI.display.Group(0, true);
greenGroup.on('sort', function (sprite) {
    //green bunnies go down
    sprite.zOrder = -sprite.y;
});

Is there any extra file i need to include in index with pixi library?

[ivan.popelyshev]

Yes, you need js file from here : https://github.com/pixijs/pixi-display/tree/master/bin

Also, if you want to use newest version of API (layers) , then its here: https://github.com/pixijs/pixi-display/tree/layers/bin , examples: https://pixijs.github.io/examples/#/layers/lighting.js , https://pixijs.github.io/examples/#/layers/zorder.js
 

At the time, both "display" and "layers" branches are supported, and you can use them depends on API that you like more. They are different, and I certainly cant decide which one is easier. 

But only "layers" branch supports lighting, filters and masks.

Also, if you need to sort stuff only inside one container, look at simpler solutions: https://github.com/pixijs/pixi-display/wiki . Nobody will judge  because you took snippet instead of big plugin for simple case.

[shashank]

Thanks ivan.popelyshev it worked.