Jump to content

Thoughts on consolidating Pixi into Phaser


Recommended Posts

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

Link to post
Share on other sites

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?

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.


Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
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...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...