These are chat archives for pixijs/pixi.js

12th
Jan 2016
Ivan Popelyshev
@ivanpopelyshev
Jan 12 2016 13:26
Micheal Winger
@mordof
Jan 12 2016 14:03
oh that is cool
Bar Ziony
@bartzy
Jan 12 2016 15:03
Does it make sense to extend WebGLRenderer?
I thought at first to write my own renderer, that "has a" Pixi WebGLRenderer and uses it internally. But besides "hiding" the fact that I'm using PIXI I didn't find any good reason for that
Ivan Popelyshev
@ivanpopelyshev
Jan 12 2016 15:04
no it does not
it makes sence make plugins for it
because almost all of the code is in plugins
SystemRenderer and WebGLRenderer is just architecture stuff
except updateTexture() method, which is hardcoded and its difficult to override it
Bar Ziony
@bartzy
Jan 12 2016 15:05
so if I write a library for use in our company, and that library "knows" how to create cards, and collages. i.e. you give it some configuration and it can render an interactive collage
it makes sense that the users of this library, will instansiate a new PIXI Renderer directly?
Ivan Popelyshev
@ivanpopelyshev
Jan 12 2016 15:06
yes
Bar Ziony
@bartzy
Jan 12 2016 15:06
and my library will mostly just be classes that extend PIXI.Container?
Ivan Popelyshev
@ivanpopelyshev
Jan 12 2016 15:06
your job is to register plugins
yep
and that too
Bar Ziony
@bartzy
Jan 12 2016 15:06
OK. But then users of my library need to know how to use PIXI.
and the ins and outs of it
Ivan Popelyshev
@ivanpopelyshev
Jan 12 2016 15:06
plugins are needed to use webgl directly
Bar Ziony
@bartzy
Jan 12 2016 15:06
Is that what Phaser is doing? It exposes PIXI directly?
Ivan Popelyshev
@ivanpopelyshev
Jan 12 2016 15:07
Phaser is moving on. And i didnt work with it
Bar Ziony
@bartzy
Jan 12 2016 15:07
Just as an example of a "library" that is using PIXI as opposed to an end product that uses it
oh ok
Ivan Popelyshev
@ivanpopelyshev
Jan 12 2016 15:07
I have some examples from other fields
Play Framework (scala) didnt expose its dependencies for some time, but then they switched directly to SBT
may be because sbt implemented what they needed
and the same goes for other aspects of that framework: they used something internelly, now they expose it
Bar Ziony
@bartzy
Jan 12 2016 15:09
ok
What I meant is , look at this example by Phaser (it's the only one I have)
var game = new Phaser.Game(800, 600, Phaser.AUTO, '', { preload: preload, create: create, update: update });
You don't create Phaser objects, then create a PIXI renderer and render these objects somehow onto PIXI. You don't even know it uses PIXI.
so I thought that perhaps it would make more sense to have something like var collage = new MyLibrary.Collage(...)
I hope you understand what I mean
it's rather conceptual
Ivan Popelyshev
@ivanpopelyshev
Jan 12 2016 15:11
Its yours to decide, but I think its better to expose PIXI
may be users will need some of its features directly
or not. i dont know :)))))
every usecase is different
for example, if you let people use their own downloaded version of pixijs as peer dependency , and something will broke in pixi then they'll have a problem
and if you embed pixijs within your library then it will be difficult for them to use your lib with newer version of pixi
Bar Ziony
@bartzy
Jan 12 2016 15:14
My lib will always include Pixi
no one will use it without my own bundled version of Pixi, or with another version
The thing is, what you say makes sense. It's like you won't try to hide the fact you use UIKit, in an iOS app. It's ridicilous
Ivan Popelyshev
@ivanpopelyshev
Jan 12 2016 15:31
you can add some interfaces that will decrease number of lines needed to use your library
that's more important aspect of exposing/embedding pixi
if you can make your interface easier, do it
Bar Ziony
@bartzy
Jan 12 2016 16:46
Stuff like wrapping PIXI renderer but still exposing it if needed?
Ivan Popelyshev
@ivanpopelyshev
Jan 12 2016 16:48
yes
Bar Ziony
@bartzy
Jan 12 2016 16:50
Like Phaser
(At least at its current version)
It's just that extending PIXI objects instead of wrapping them (is-a relationship and not has-a)
Is polluting theses objects with lots of PIXI methods and properties
I mean, I have a Layer class. If it has-a PIXI.container (something you didn't recommend), then its public API is entirely what I decide.
if it is-a PIXI.Container, then it inherits all of PIXI's methods and members for PIXI.Container.
Which makes it quite "heavy"
if you get what I mean
Bar Ziony
@bartzy
Jan 12 2016 18:08
@ivanpopelyshev ? :)
Ivan Popelyshev
@ivanpopelyshev
Jan 12 2016 18:15
hm
its not that heavy actually
Bar Ziony
@bartzy
Jan 12 2016 18:47
all these public property :D
properties*
for example, x/y/width/height and stuff, and perhaps I have equivilant properties with the same name but that behave a bit different.. Then I need to find them my own name
:D
But I agree, I already started extending PIXI and exposing it, and not to try to hide it. I will continue with that.
thanks
Dave Moore
@themoonrat
Jan 12 2016 19:03
Bartzy, im going through a similarish decision with my company, and i think we will go with exposing it. I like to have a constant interface, and the idea that some parts of PIXI could be hidden, some not.... just gets confusing to users i think. Much easier to go, here is the PIXI interface, it works, it's tested, and it's documented with plenty of examples and tutorials online.
Anything that saves me documenting is a good choice ;)