rich Posted February 5, 2016 Share Posted February 5, 2016 (edited) 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 February 5, 2016 by rich Added multi-batch comment drhayes 1 Link to comment Share on other sites More sharing options...
stamas47 Posted February 5, 2016 Share Posted February 5, 2016 Would this fix screen tearing that sometimes occours on certain screens? Link to comment Share on other sites More sharing options...
rich Posted February 5, 2016 Author Share Posted February 5, 2016 4 minutes ago, stamas47 said: Would this fix screen tearing that sometimes occours on certain screens? No, that is an issue outside of any JS framework. Link to comment Share on other sites More sharing options...
stamas47 Posted February 5, 2016 Share Posted February 5, 2016 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 More sharing options...
ekeimaja Posted February 5, 2016 Share Posted February 5, 2016 Don't bother to this, if you make Lazer with own renderer. It's just waste of time imo. Link to comment Share on other sites More sharing options...
alex_h Posted February 5, 2016 Share Posted February 5, 2016 You mean pixi.js v3, right? Or is there a v4 now that I don't know about? [Edit] - Oh, I stand corrected - there is a v4 in dev it seems! Link to comment Share on other sites More sharing options...
WombatTurkey Posted February 5, 2016 Share Posted February 5, 2016 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 More sharing options...
rich Posted February 5, 2016 Author Share Posted February 5, 2016 10 minutes ago, alex_h said: You mean pixi.js v3, right? Or is there a v4 now that I don't know about? [Edit] - Oh, I stand corrected - there is a v4 in dev it seems! Yup, v4! So everyone used to v3 will have to get used to v4 now Link to comment Share on other sites More sharing options...
enriqueto Posted February 5, 2016 Share Posted February 5, 2016 develop Lazer instead Link to comment Share on other sites More sharing options...
qdrj Posted February 5, 2016 Share Posted February 5, 2016 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. Link to comment Share on other sites More sharing options...
igor.kroppli Posted February 5, 2016 Share Posted February 5, 2016 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 More sharing options...
rich Posted February 5, 2016 Author Share Posted February 5, 2016 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 More sharing options...
rich Posted February 5, 2016 Author Share Posted February 5, 2016 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 More sharing options...
JakeCake Posted February 5, 2016 Share Posted February 5, 2016 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 More sharing options...
Skeptron Posted February 5, 2016 Share Posted February 5, 2016 I'd say stick to developping Lazer. No need for Pixi v4 Link to comment Share on other sites More sharing options...
WombatTurkey Posted February 5, 2016 Share Posted February 5, 2016 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! Link to comment Share on other sites More sharing options...
strivinglife Posted February 5, 2016 Share Posted February 5, 2016 I agree with the others in that Lazer dev makes more sense since you're doing Pixi in that. Link to comment Share on other sites More sharing options...
rich Posted February 5, 2016 Author Share Posted February 5, 2016 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 More sharing options...
rich Posted February 5, 2016 Author Share Posted February 5, 2016 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? WombatTurkey 1 Link to comment Share on other sites More sharing options...
WombatTurkey Posted February 5, 2016 Share Posted February 5, 2016 7 minutes ago, rich said: If only a bunny mark was representative of an actual game aye? Ya don't mean the average HTML 5 game that get's released right? Just kidding, in all seriousness, good point lol. Link to comment Share on other sites More sharing options...
sombriks Posted February 5, 2016 Share Posted February 5, 2016 Do the huge and bold move to v4! The benefits worth the risk. Link to comment Share on other sites More sharing options...
stupot Posted February 5, 2016 Share Posted February 5, 2016 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 More sharing options...
rich Posted February 5, 2016 Author Share Posted February 5, 2016 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 drhayes 1 Link to comment Share on other sites More sharing options...
dr.au Posted February 5, 2016 Share Posted February 5, 2016 Lazer focus! Link to comment Share on other sites More sharing options...
stupot Posted February 5, 2016 Share Posted February 5, 2016 You're probably right about it being WebGL, I still generally experience a slowdown in WebGL (still very device specific) and don't use tilemaps. Link to comment Share on other sites More sharing options...
Recommended Posts