Jump to content

Thoughts on consolidating Pixi into Phaser


rich
 Share

Recommended Posts

I'll let you have this one, without any rebuttal (we live in this 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.

You sound crazy :D

 

Just kidding. There was no other possibility. Things had to be added to PIXI for Phaser, but not to the PIXI repo itself. So, right now, going to PIXI 3 would mean migrating all these additional features.

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

 

If we were to revert back to following Pixi with no deviation we'd have to remove a significant number of features from Phaser. Not just a few. A lot. But worse than this we'd need to put back in a good pile of bugs as well.

 

We have never, not even from day 1, used Pixi fully in Phaser. It has always been a customised build. It was the right decision then and it's still the right one now. Yet despite this if you remove Goodboy Digital staff from the list, I personally am still the 3rd highest contributor to the Pixi codebase, even though I haven't issued a PR there in nearly a year. I've spent months and months of my development life helping it for the good of everyone. Even if you didn't use Phaser and just used Pixi, you are still benefitting massively from the work I put into it.

 

I understand intimately how Pixi development cycles work. How when Mat is stacked up with client work (like he has been for ages now) that Pixi effectively grinds to a halt. It's not his fault, he has a company to run and staff to pay, and those come first (as they should). But it got to the point where it slowed down what was possible in Phaser. Which is why we've invested thousands of $ in building a new renderer, and spent almost a year on it so far. It's the same reason run our own fork of Pixi too: so we can march at our own pace, and not have that pace dictated to us by anyone else.

 

Using Pixi in Phaser was the best decision I could have made at the time. It allowed us to do so much, so quickly. And I've paid my dues for that, both in terms of contributions and promotion (Phaser games account for a huge number of entries on the Pixi showcase page). But times change, and soon it will be time to move on.

 

It's easy to say it was a 'mistake' (without any actual reasoning given.) I guess that's probably why even though Phaser is used inside your game, you decided to hide the fact. Disabling our banner yet enabling the Pixi one. Not that I care, lots of companies disable our banner, it just amused me the Pixi one was put back in. Like some kind of obscure dig.

Link to comment
Share on other sites

I'm sorry but the last line on the above post made me laugh, I'm sure there was an awkward moment there.

 

Anyhow back on topic

 

1) No

2) No

3) I define them specifically, usually its just Canvas but lately have been experimenting with WebGL features.

 

I think its a good call, Phaser is gaining momentum and it should not stop for anything. Basically you had me at clearing up the Docs (although they are much better now).

Link to comment
Share on other sites

  • 2 weeks later...

If we were to revert back to following Pixi with no deviation we'd have to remove a significant number of features from Phaser. Not just a few. A lot. But worse than this we'd need to put back in a good pile of bugs as well.

 

We have never, not even from day 1, used Pixi fully in Phaser. It has always been a customised build. It was the right decision then and it's still the right one now. Yet despite this if you remove Goodboy Digital staff from the list, I personally am still the 3rd highest contributor to the Pixi codebase, even though I haven't issued a PR there in nearly a year. I've spent months and months of my development life helping it for the good of everyone. Even if you didn't use Phaser and just used Pixi, you are still benefitting massively from the work I put into it.

 

I understand intimately how Pixi development cycles work. How when Mat is stacked up with client work (like he has been for ages now) that Pixi effectively grinds to a halt. It's not his fault, he has a company to run and staff to pay, and those come first (as they should). But it got to the point where it slowed down what was possible in Phaser. Which is why we've invested thousands of $ in building a new renderer, and spent almost a year on it so far. It's the same reason run our own fork of Pixi too: so we can march at our own pace, and not have that pace dictated to us by anyone else.

 

Using Pixi in Phaser was the best decision I could have made at the time. It allowed us to do so much, so quickly. And I've paid my dues for that, both in terms of contributions and promotion (Phaser games account for a huge number of entries on the Pixi showcase page). But times change, and soon it will be time to move on.

 

It's easy to say it was a 'mistake' (without any actual reasoning given.) I guess that's probably why even though Phaser is used inside your game, you decided to hide the fact. Disabling our banner yet enabling the Pixi one. Not that I care, lots of companies disable our banner, it just amused me the Pixi one was put back in. Like some kind of obscure dig.

 

Admittedly my post was misinformed, I posted in this thread thinking it was about forking away from Pixi, even though Phaser has always had its own customized build. I have now brought myself up to speed by browsing these forums.

 

As to the the Phaser banner in the console, we did not remove it on purpose!

 

When we decided to port Phaser to Browserify and integrate it with Pixi.js v3, some of the code simply wasn't carried over. I'll make sure that we put the Phaser banner back in. We also plan to have a Phaser splash screen w/ a link back to Phaser's website once the game is finished.

 

Overall, getting the latest Phaser to work with Pixi v3 was successful, but time consuming. We'd be willing to share the code on Github if its ok. The biggest benefit we have experienced under Pixi V3 is better support for GLSL shaders, like our planet shader.

 

Once again, awesome work! We plan to use Phaser v3 on our next game.

Link to comment
Share on other sites

Here are my answers to questions:

 

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

No, but sometimes I am referring it as method parameter or member variable type, because currently Group inherits from DOC which inhertis from DO. Phaser.Sprite inherits from PIXI.Sprite from DOC from DO. So, first common ancestor for Group and Sprite is DOC. Would it mean that new hierarchy would be like: Phaser.DO -> Phaser.Group -> Phaser.Sprite? Or Phaser.DO -> Phaser.Sprite and Phaser.DO -> Phaser.Group? It is convenient to have sprite as ancestor of some container as you can add children to it if needed, but it is not necessary.

 

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

No

 

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

Auto most of the times

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

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