Pixi v4 Support

[Avery-Whitaker]

No description provided.

[Avery-Whitaker]

Tried using with v4 app and did not work. This is a great library but needs updating to stay relevant.

[kittykatattack]

Yes, smoothie only works for Pixi version 3.x at present.
I'll consider version 4 support when it finally stabilizes.

[griest024]

@kittykatattack would you still not consider Pixi.js stable? It is at 4.5.5 currently. What do you think about starting a v4 branch for experimental v4 support?

[kittykatattack]

@griest024 Yes, this is a long term project of mine, so it will eventually move to version 4.
Can anyone out there who's tried using Smoothie with Pixi 4.5.5 report the errors they've recieved?

[griest024]

@kittykatattack I can do it, though I may not get to it tonight. What would you think about publishing these projects on npm, possibly after combining them into a single package. I'm talking about the projects that Hexi uses, Charm, Smoothie, Dust, etc.

Would you be open to reviewing some PRs to this effect? I think some unit tests would also make migrating to v4 (and later versions of Pixi.js) much easier.

[kittykatattack]

Hi @griest024!

Regarding npm, Hexi is a mega-framework, and npm seems best suited for modular utilities? However, please make your case if you feel that npm is important. What might sway me is if I can be convinced that it will simplify Hexi's architecture, protect the code from 3rd part dependencies, and and make it more maintainable 😄. I definitely don't have the experience to publish Hexi to npm so I would need some help if that happens, and it might overall be best to wait till v.0.1 is finished first (?)

Regarding Hexi's modules, these have to remain stand-alone so that they can be used with vanilla Pixi. (Hexi is just a very thin layer of glue code on top of Pixi.)

[griest024]

these have to remain stand-alone so that they can be used with vanilla Pixi

Well the modules themselves could remain isolated, but I think it would be simpler to combine them into a single repository. In fact, even if all the modules were in a single repository, you could still publish each module as a separate npm package with a single command.

However, please make your case if you feel that npm is important. What might sway me is if I can be convinced that it will simplify Hexi's architecture, protect the code from 3rd part dependencies, and and make it more maintainable

Actually I don't really care about Hexi at all, I'm using the modules with vanilla Pixi.js. From what I can tell though, Hexi is both a thin layer of glue between the modules and Pixi.js and a boilerplate project. With this in mind, publishing as a npm package would have the following benefits:

• Provide a CLI to initialize a Hexi project scaffold and perform other tasks
• More explicit dependency management of modules and Pixi.js (no more messing around with submodules); this kind of requires publishing modules on npm as well
• Integrate nicely with modern JS build tools (webpack, etc.)
• More friendly to modern development environments (import)
• Streamline delivery of your distributables through a free CDN

More on that last one, unpkg provides automatic, free CDN for every single public package on npm. Better than linking directly to files in the repo.

In short, it would modernize the Hexi project.

I definitely don't have the experience to publish Hexi to npm so I would need some help if that happens, and it might overall be best to wait till v.0.1 is finished first (?)

I would be happy to help 😃.

[griest024]

@kittykatattack I've started a repo to show you what I mean https://gitlab.com/griest/pexi

[kittykatattack]

@griest024 That's awesome, thanks so much for doing that!

[griest024]

@kittykatattack how would you feel about moving development over to my fork of the project? I have set up a workflow so that a CI server will automatically run tests, report test to a static site hosted on gitlab, build the projects, and publish each package to npm.

Since you know these projects the best it would be helpful if you could write some unit tests.

[kittykatattack]

@griest024 I have some long-term future plans for these libraries, but by all means please go ahead with your fork and publish to npm if you feel it's viable. Sadly, I'm too time-constrained at the moment to help with unit testing.

[CloverFeywilde]

I build my game on Pixi 4.0 and am stunned to find out that pixi doesn't have a way to smooth out frame animations if your apps framerate is controlled by a delta. I mean common! How in any way is that acceptable for a rendering engine? What's the alternative here? Not use a delta and have software that runs in the blink of an eye on newer machines and lags on others? I digress..

This script is basically my only option I'm seeing right now. Pixi is on version 4.7.1.. Is it not mature enough yet for your taste? :c I know it's a lot to ask, but is there any way this script can be ported to pixi v4 sooner rather then later?

My game project is stalled until I can find a way for my animations to run smoothly while controlling the framerate with a delta. So If I have to I can try taking a look at this. Though I'm mainly an artist that happened to barely become functional with javascript enough to script simple games. Not sure how much help I can offer here in the ream of software development. But I can fork this and give it a try if needed.

Also, I wish I saw Hexi a long time ago. Because I've basically been using nothing but your scripts @kittykatattack to make my game functional. From what I can see, Hexi is pixi with all of those scripts loaded in from the getgo.

[ajakaja]

If anyone is interested, I copied smoothie.js into my project and modernized it, cause I didn't want to write something similar from scratch. I updated it for typescript + Pixi 5. I'll probably submit a PR when time permits but in the meantime here's the file: https://gist.github.com/ajakaja/04e5d9f7ce79319e382d18f7084d97f2