Thoughts on consolidating Pixi into Phaser

[rich]

Hi all,

 

Just wanted to throw this out to the wider community before I started work on it (or indeed if enough people say 'no!' then I'll abandon the idea)

 

As you know Phaser uses its own custom build of Pixi, and has done for a while now. There are many Phaser unique features in our Pixi build and a whole load of fixes.

 

What I'd like to do is carry on consolidating Pixi into Phaser, so they are no longer two separate packages or name spaces. For example I'd like to:

 

1) Remove the DisplayObject, DisplayObjectContainer and PIXI.Sprite classes entirely. In terms in inheritance right now, Phaser Sprite inherits Pixi Sprite, which inherits from DOC, which inherits from DO. This seems pointless to me - it makes a lot more sense to merge all of these into a single Phaser Sprite class. The benefit will be that I can tidy-up the docs a lot by doing this, and also make the class smaller as I can remove methods like PIXI.Sprite.fromImage which aren't even used. Do you ever create PIXI.DisplayObjects directly in your games?

 

2) Remove the PIXI Globals. This is a larger task, but it would mean stopping PIXI from needing to be a global window level var (which currently causes issues in setups using Webpack and similar). A single Pixi instance would become part of Phaser, and I'd do away with the PIXI global. Do you use PIXI globals anywhere in your code?

 

3) Split up the renderers - so you can optionally include Canvas and/or WebGL. If you know your game isn't using WebGL (or Canvas) then you don't need any of those classes at all, so I'd like to work through making them properly split out. Do you always use AUTO render type, or do you target a specific type?

 

Thoughts?

 

Cheers,

 

Rich

[yahiko]

PIXI inheritances create useless and pointless overhead in my mind when I read documentations.

 

PIXI implementation should be a private matter for Phaser and not be used directly by end-users.

[tips4design]

Hello Rich,

 

1) No

2) No

3) For some apps I used AUTO, but for games exported to mobile I only use CANVAS.

 

So, you are planning to only include what is needed from PIXI and maybe refactor it. What about PIXI updates? Are you going to give up the updates done for PIXI?

I like the idea of keeping it cleaner but I dislike the possibility of people working on the same bug on two different projects. Are you going to use the current version of PIXI when you make this changes or try to directly integrate PIXI  v3?

[rich]

Pretty much since the start Phaser has only used what it needed from Pixi (rather than the entire library), and it completely replaces lots of Pixi classes. We've not used a 'mainstream' build of Pixi for a good while now.

 

There will be no update to Pixi 3 in this change. While it would give us a few enhancements it would also remove lots of functionality we've directly added. It's just too much of a change to undertake. What I'm detailing above is just house keeping really.

[drhayes]

1. No.

2. No.

3. I haven't used AUTO yet; for pixel art I need CANVAS, for anything else I just specify WebGL.

 

I mean, I *guess* the fallback is nice? But realistically I want to know the performance boundaries of my games and not let it be specified at run-time on the user's computer.

[qdrj]

1) No

2) No

3) Yes, I always use AUTO.

 

Yes, it will make code clearer and easier to understand.

 

But it is huge update/refactoring and so why do this if next major version will be using own renderer. Current order of things works great.

 

I would say it will bring a little "gain" over big amount of work. I think there are better directions to improve Phaser 2x.

[rich]

The main reason for doing this is to solve the issues Phaser has with the likes of Webpack - it would remove the need for populating the global space entirely.

 

Also I don't think it's a huge undertaking, or I wouldn't even be considering it.

[sodomo]

1. No.

2. No.

3. I always use canvas, because of iOS performance problems with webGL...

So if it's not a huge task and it solves webpack issues - go for it. I think most of the people would not even notice any change or experience any problems because of that.

[sapptime]

1) No

2) Very rarely - in a couple of cases I've added utility methods to some core pixi classes so they trickle down to anything extending them, but these could be easily moved.

3) I mostly manually define the renderer due to the issues mentioned above.

 

I'd say go for it. 

[wayfinder]

I don't create DisplayObjects directly, but some of the extended objects I use call DisplayObjectContainer.destroy directly. I'm also using my own implementation of triangle strips that extends PIXI.Strip directly. And I keep an add-ons file with a bunch of pixi functions that I have changed to fit my needs, or bugfixed (mostly strip, graphics and renderer related). 

 

I specify WEB_GL and do not use AUTO, my current game will not work on canvas.

[drhayes]

I'm not sure what Webpack issues other people are seeing. I've been using Webpack to package my game and haven't seen any problems.

[stupot]

No, no, no

[Tilde]

I specifically use Canvas because of your blown-up pixels tutorial.

[Noid]

1)No

2)No

3)Yes, but I'm considering switching back to canvas. In those devices where webgl works well, I haven't noticed any performance penalty by switching to canvas. However, there many devices that claim to have webgl support and it doesn't actually work very well(or at all). 

 

Consolidating Pixi into Phaser seems to be a lot of effort considering that Phaser 3 will have it's own renderer, but I'm sure you have already considered this and think it's worth the effort anyway.

[nkholski]

1. No

2. No

3. Mostly I just go for AUTO, except when testing on mobile.

 

Sounds like a good idea, but I can't imagine where you find time to do all things you're doing. Do you ever sleep?

[enriqueto]

1. No

2. No

3. I use canvas

[codevinsky]

1) Do you ever create PIXI.DisplayObjects directly in your games?

Not as such, no. However, I do -often- use the inherited abilities of DO's and DOC's to add child sprites to sprites.

 

2) Do you use PIXI globals anywhere in your code?

 

 

3) Do you always use AUTO render type, or do you target a specific type?

Most of the work -I- do is web work using Phaser as an animation layer. As such, I -always- use AUTO as we have to support a lot of different browsers and platforms. However, I'm not opposed to having to include modules.

 

 

That being said:
I am ALL about being able to use webpack and correct es6 module and class structure for my projects. Right now, it's a mish-mash of what can and can't be done. So, whatever it takes to be able to have Phaser be correctly modularized... I'm for it.

[BunBunBun]

1. No

2. No

3. Mostly I just go for Canvas.

[mwatt]

These kinds of things are always worse than one thinks.  You are going to introduce a lot of bugs.

 

To me, this seems worthwhile only if Phaser 3 is quite far out on the horizon - like a year or more.  Otherwise, work on Phaser 3 and forget about this is my advice.

[rich]

Some parts are quite trivial to do - for example getting rid of the DisplayObject hierarchy wouldn't take long at all. Splitting the renderers up would take longer, and it sounds from the comments above that it's not worth doing either. So I think I may do just the first and maybe second parts of the plan and leave the third.

[netcell]

Regarding number 2, I am currently using PIXI.BaseTextureCache and PIXI.Texture for processing new Textures in a Nine Patch plugin so...

 

Nvm, I fixed my code with the release. However, someone out there might have similar problem

[horkoda]

1. no, but I use various pixi classes

2. yes, rarely (some constants I use with other pixi classes)

3. Canvas only

[hilary_craven]

Pixi.js and and Phaser.js breaking up is not good for anyone... Especially since HTML5 and WebGL game development is still considered a toy by many professionals.

 

My team and I have been working on a game called Solar Crusaders, and we have the latest Phaser working with the latest Pixi.js 3.0, with somewhat minimal effort... so why is there a fork...? what is going on, why fork off something that already works so well? our tech demo and code can be tested at http://solarcrusaders.com/

 

For many developers this uncertainty just turns them off from developing using HTML5 and WebGL using Phaser/Pixi ... and mind you, there are strong competing technologies such as BabylonJS.

 

EDIT: I'm somewhat biased, I don't have time to wait for Phaser to create a whole new engine 1+ years from now.

[rich]

I'm confused. This topic is nothing to do with Phaser and Pixi separating. It's simply about consolidating some legacy Pixi classes.

 

We've been running our own fork of Pixi for a long time now, with many customisations and enhancements not found in Pixi 2 or 3.

[hilary_craven]

I'll let you have this one, without any rebuttal (we live in the code.) But I firmly believe that forking from Pixi has been / is a mistake. Yes you can probably make it slightly better, without relying on libraries you don't like... but WHY??

 

EDIT: I don't mean to sound crazy, we all make decisions that we think are right, and I firmly believe in your decision. I stand by what you think is the way to go.