Jump to content

Should we merge Pixi v4 with Phaser?


rich
 Share

Recommended Posts

This is a cross-post from the Phaser Patreon account.

I've been working hard on the Phaser 2.4.5 update recently, closing off countless issues on GitHub and implemented fixes and updates. And there is a re-occurring theme I'm noticing which bothers me: essentially, Phaser is paying for its decision to stick with version 2 of Pixi.

I've done a lot to fix issues directly but there are some that would only be solved by moving to a later release of Pixi, especially when it comes to problems around Graphics rendering and masks.

So I'm left with a dilemma and need your thoughts to decide on the best course of action. The options as I see it are:

1) Do nothing. I carry on fixing what issues I can in Phaser, but if they are just too deep down the Pixi well then they are left un-fixed.

2) Take Pixi v4 and merge it with Phaser. This is a major task, it will not be an easy integration. There are two major problems: First I've added a lot to Pixi over the years to make it work more nicely with Phaser (the CanvasPool for example). Secondly Pixi v4 is a complete re-structuring. I would have to redo the entire Phaser build process, recode how Phaser uses Pixi and extends Pixi objects, and make some huge sweeping changes. It would be a significant API overhaul.

Part of me really wants to pick option 2, because I don't like seeing issues left unresolved in Phaser. I guess it's a pride thing, rather than a logical one though. 

So I'd like to know your thoughts on this. How would it directly affect you and what you're doing? It would be such a massive change to Phaser that you are very unlikely to be able to just run an existing Phaser 2 game under Phaser 3 (or whatever version we use). Also don't assume it will give your game any kind of significant performance increase - the core underlying sprite batching in Pixi hasn't changed all that much (edit: actually it now has multi-texture batching, which is pretty sweet, so yes you're likely to see a speed increase in some cases) - where it has changed (especially around Graphics) it would be very noticeable.

Please don't under-estimate the sheer volume of work involved in picking option 2. It is not a trivial step, will require a major version release and weeks of dev time. And you could rightly argue maybe that is time better spent on Lazer instead.

Edited by rich
Added multi-batch comment
Link to comment
Share on other sites

Considering that Lazer will be using a whole new rendering engine I personally think it's not worth invesing time on overhauling the underlying Graphical system if no major advantages come from it. 

I dont want to tell you what to do but I think you should concentrate on Lazer, bringing us the future of WebGL/Canvas gaming!

Link to comment
Share on other sites

Well, I'm around 35k lines of code in for my aRPG within Phaser. I think #2 would be cool just because I don't want to convert everything to Lazer.

But, as you said there will be really no 'dramatic' performance gains so I guess I really don't care.  I could always just port the 35k+ lines of code over to Lazer later.

So I agree 100% with @ekeimaja, don't even bother to do it. I think your precious time should be put into Lazer.

Link to comment
Share on other sites

Agree with stamas47, it's better to continue work on Lazer. 

New big HOTFIX changes, as like as i see #2 point, always produced new bugs (small and big ones). Especially since Lazer is planned to use an entirely new renderer it's just unpleasant waste of time. 2-3 weeks, which #2 could took, also might affect a lot emotionally. And it is very difficult then reconfigured back to work on Lazer, i think.

p.s. I suggest the #3 point. Return to this question only after new Laser's renderer will be presented and worked. And then create, for example, new separate Phaser2-Pixi4 branch just to keep the refactoring in some "sandbox" place.

p.s.s. As i know, Pixi's main developer said (somewhere in one of the topics in this forum) that he has no much time to maintain his stuff. So Pixi v4 can also bring more other bugs...

Link to comment
Share on other sites

5 minutes ago, qdrj said:

It would be great if multitexture batching will be implemented in Phaser 2.

But I say - stick with option 1. Spend development resources on Lazer development. Yes, Phaser 2 have some small issues here and there but overall it is a very solid engine.

That's a very good point - I forgot Mat had added this. Multitexture batching could help lots re: rendering speed. Like all things these days it only applies to WebGL of course, but is still a really nice feature. Even so, it's still a large refactor for Phaser just to gain this (and the other fixes of course). Choices, choices!

Link to comment
Share on other sites

3 minutes ago, northducks said:

Agree with stamas47, it's better to continue work on Lazer. 

New big HOTFIX changes, as like as i see #2 point, always produced new bugs (small and big ones). Especially since Lazer is planned to use an entirely new renderer it's just unpleasant waste of time. 2-3 weeks, which #2 could took, also might affect a lot emotionally. And it is very difficult then reconfigured back to work on Lazer, i think.

p.s. I suggest the #3 point. Return to this question only after new Laser's renderer will be presented and worked. And then create, for example, new separate Phaser2-Pixi4 branch just to keep the refactoring in some "sandbox" branch.

p.s.s. As i know, Pixi's main developer said (somewhere in one of the topics in this forum) that he has no much time to maintain his stuff.

Yes you're right, making this change would absolutely introduce new bugs too. So maybe the end result is that yes, Phaser gets Pixi 4 and is faster and has less rendering bugs, but I would now have to be solving new bugs in Phaser as a result of the change AND trying to work on Lazer at the same time. There are only so many hours in the day ...

Link to comment
Share on other sites

For me, it depends on how far away Lazer is from it's initial release. At this point it's been more than 4 months since the last minor Phaser version, so if Lazer is still a year away, I would very much like to see a large update to Phaser in 3 weeks instead, but if Lazer is around the corner, then I see no reason to do anything but fix minor issues for Phaser.

Link to comment
Share on other sites

51 minutes ago, JakeCake said:

For me, it depends on how far away Lazer is from it's initial release. At this point it's been more than 4 months since the last minor Phaser version, so if Lazer is still a year away, I would very much like to see a large update to Phaser in 3 weeks instead, but if Lazer is around the corner, then I see no reason to do anything but fix minor issues for Phaser.

It won't take 3 weeks to integrate Pixi 4, more like several months work. Lazer is not 'around the corner' though.

Also it hasn't yet been 4 months since Phaser 2.4.4 either ;) (on February 15th it will be, but 2.4.5 will be out by then)

Link to comment
Share on other sites

48 minutes ago, WombatTurkey said:

Wait, would the  multi-texture batching feature effect the performance of the amount of sprites being drawn on the screen? (If added to Phaser)

Edit: Because I just saw that multi batch example with v4, and holy shit!

If only a bunny mark was representative of an actual game aye? :)

Link to comment
Share on other sites

My vote is to use your time on Lazer instead of integrating PIXI V4 into Phaser2.  If it was a drop in update then we'd probably all selfishly say to integrate it.

I think right now, fixing up Phaser to be stable and performant would see us through until Lazer is a good enough dev candidate.  There's plenty of talk about 2.4 being slow, it doesn't seem right that this version should end in this way.

Of course multitexture batching would be a nice addition.

Link to comment
Share on other sites

It's interesting because for all the "it's slow" comments (and I do see them) no-one is yet to provide me with a proper solid test case I could actually debug.

The way Phaser renders things hasn't changed for ages now, and the internal Pixi code hasn't changed either.

Most of the comments I see are all to do with Tilemaps, which have always been a point of contention - devs seem to kick Phaser into WebGL mode, render a tilemap and then wonder why it scrolls slowly on mobile. It's bound to. Perhaps part of the issue here is that with more mobiles making WebGL enabled, we're seeing where it falls over more, as before it used to just use canvas anyway.

Who knows.. it's all a bit of guess work really, although well educated guess work.

Putting Pixi 4 in isn't likely to solve any of the issues re: Tilemaps. It will solve Graphics issues, mask issues and provide a speed-increase with its multi-texture support. But it will do so at a significant time cost, and we'd be back on the 'final frontier' again dealing with a brand new build of Pixi. Which is both exciting and worrying in quite equal measure. It'd be a change so big I couldn't even call it Phaser 2.4.x

Link to comment
Share on other sites

  • rich unpinned this topic
 Share

  • Recently Browsing   0 members

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