These are chat archives for pixijs/pixi.js

24th
Jan 2016
mdimai666
@mdimai666
Jan 24 2016 01:13
Hi people. Can you help me? I'am looking isometric engine in pixi.js, please talk about it? (from russian)
Ivan Popelyshev
@ivanpopelyshev
Jan 24 2016 01:54
поздновато ты пишешь. давай завтраа. vk.com/popelyshev
@mdimai666 phaseer supports isometry, but its better to code it yourself. i can consult you tomorrow
Bar Ziony
@bartzy
Jan 24 2016 14:31
@ivanpopelyshev How did old-gen engines do it?
And, unrelated, does PIXI uses off-screen rendering pass(es) for masks?
i.e. if a sprite has a mask on it, it needs to render its entire tree off-screen and not directly in the frame buffer, right? Then apply the mask, and only then render that entire output to the framebuffer?
And that's the case for each mask (for example if in that sprite, a descendant sprite has a mask, it does ANOTHER off-screen rendering pass to render it and all its children?
Ivan Popelyshev
@ivanpopelyshev
Jan 24 2016 14:35
yep
Bar Ziony
@bartzy
Jan 24 2016 14:37
Where is the code for that?
if you can guide me to the right file
And basically, that means that masking is quite an expensive task, right?
Ivan Popelyshev
@ivanpopelyshev
Jan 24 2016 16:08
that depends on sprite sizes :)
Chad Engler
@englercj
Jan 24 2016 16:29
Masking doesn't require rendering the scene offscreen and then applying the mask.
For a WebGL Graphics mask, we use the stencil buffer to draw the mask then apply it using a color mask stencil operation, it interrupts the batch but doesn't require us to render the entire scene offscreen or anything
For Canvas Graphics we use clip, just draw the path and clip it
For Sprite (alpha) masks we use a custom shader that is applied as a filter, so again it interrupts the batch. Sprite (alpha) masking isn't available on Canvas
Bar Ziony
@bartzy
Jan 24 2016 16:58
What do you mean by "interrupts the batch"?
And thanks for the info
And, unrelated again, why didn't you use Point in Rectangle for example?
i.e. have a "origin" member on Rectangle instances that is a PIXI.Point
Chad Engler
@englercj
Jan 24 2016 17:18
When you have a container, and all the children share a texture and shader (which by default they share a shader) then they are "batched" together
meaning we iterate them and prepare their data but don't draw until we have to, at which point we make a single gl draw call to draw many sprites at once
that is where most of pixi's speed comes from, the batching
When you add filters, a mask, change the shader, change the texture, etc
of one of the sprites in the middle of that list
then you "break the batch"
what that means is as we are walking the tree, we are batcfhing up all the similar sprites, then we hit something different so we need to flush
we do a gl draw for what we have so far, then start a new batch
Bar Ziony
@bartzy
Jan 24 2016 19:29
Cool
So you're walking the tree several times, right?
Seeing what you can batch, and what not etc
oh, no, sorry
just re-read your last sentences
Micheal Winger
@mordof
Jan 24 2016 19:30
only takes one walk to determine batches
at least, under normal circumstances that's the case
(i have no idea how pixi actually does it)
Bar Ziony
@bartzy
Jan 24 2016 19:30
but if a sprite (or all sprites) have a shadow for example, that breaks the batch as well, right?
Micheal Winger
@mordof
Jan 24 2016 19:31
yeah, it breaks up the batch - i just meant that determining those batches would still only be one walk
Bar Ziony
@bartzy
Jan 24 2016 19:31
yeah got it
Micheal Winger
@mordof
Jan 24 2016 19:32
depends how you're doing the shadow for the sprite though. if the shadowed-sprite is in the same base texture, it wouldn't have to disrupt the drawing batch
Bar Ziony
@bartzy
Jan 24 2016 19:33
@englercj Can you perhaps answer my Rectangle question? I wonder about, one is why you "flatten" the Rectangle by having 4 floats instead of a "Point" object and a "Size" object to represent a Rectangle for example, and the second is why these stuff (Point, Rect, value-types...) is not immutable?
Sorry if this is unrelated.
I'm just going over some of the code and I was interested on some of the principles and design choices
Micheal Winger
@mordof
Jan 24 2016 19:33
i can't help with those at all - only thing: i would dislike it if they were immutable
since that's not really javascripts' style
Chad Engler
@englercj
Jan 24 2016 19:36
Do we need to use Point for some reason? Seems like it would be making the object heavier for no benefit
Ivan Popelyshev
@ivanpopelyshev
Jan 24 2016 20:45
@Bartzy immutable points are evil in renderer :)
Bar Ziony
@bartzy
Jan 24 2016 21:37
@englercj Since it exists as the "standard" way to represent a Point, I thought it would make sense to use them everywhere
@ivanpopelyshev Why? :) You don't write while rendering I guess...
@englercj And as for the immutability argument? :)
Chad Engler
@englercj
Jan 24 2016 21:39
Meh, using point could make sense for the origin. but a point for size isn't semantically a nice api
as far as immutability, creating objects in JS is stupid expensive
immutable objects mean you get to create a shitload of them all the time
Micheal Winger
@mordof
Jan 24 2016 21:40
it's also easier just to modify the ones already in use when you need to update them (in my opinion)
Bar Ziony
@bartzy
Jan 24 2016 21:43
@englercj But you need to create them anyway if you return them as objects from anything, to avoid aliasing
and when you receive a point and you need to store it (as a DisplayObject or whatever), you need to copy it and not use the direct point since that could be dangerous...
Micheal Winger
@mordof
Jan 24 2016 21:45
... to avoid aliasing...?
Chad Engler
@englercj
Jan 24 2016 21:46
Most of our functions that return a point can take in an "out" parameter that will modify that point instead of creating a new one
otherwise it creates a point and returns it, at which point you take ownership of that object
also "aliasing"?
Bar Ziony
@bartzy
Jan 24 2016 21:47
I guess that's Java terminology
I mean when you have a View for example that has a center Point or whatever. and it has a setPoint(point) method. if you do this._center = point, you're "aliasing"
so whoever gave you that point, now control your center point and you don't know about it. So you need to clone it when you set it.
Micheal Winger
@mordof
Jan 24 2016 21:49
oh
that's an object reference
extremely common in javascript
since all objects are passed as references anywhere to methods.. it's actually a lot more difficult to clone objects than just working with the fact that it's references
Bar Ziony
@bartzy
Jan 24 2016 21:50
Yes. But in cases like setters, you don't want it to behave like that. It can introduce very weird bugs. So you either flatten out the data structure (i.e. save x/y floats on your object instead of Point), or you copy the Point you get.
Micheal Winger
@mordof
Jan 24 2016 21:51
eh.. to each their own.
javascript is my primary language - i actually find it more annoying when i can't pass objects around as references all over the place when i try to work with other languages
and only in very rare cases do i ever find a need to copy one to prevent that scenario
like with my current pixi project - i have a bunch of graphics and sprite objects. I update a lot of the internal data they store when i modify them so i can create my modifiable terrain. i'd have to do a ton of new object creation/swapping to achieve that
as it is now, i simply store a reference to the possible options - and when i update a tile to a different type, just pass it the new reference it should use for collision checks and rendering
Bar Ziony
@bartzy
Jan 24 2016 22:01
The problem is when you do something like:
point = new Point(50, 50);
view.center = point;
...
mordof @mordof doesn't see that as a problem
Bar Ziony
@bartzy
Jan 24 2016 22:02
renderer.whatever = point
Micheal Winger
@mordof
Jan 24 2016 22:02
you can also then use that point to do other calculations surrounding the center of the view
Bar Ziony
@bartzy
Jan 24 2016 22:02
then you have 2 completely unrelated parts of your program that are now very tightly coupled. It can introduce crazy bugs
Micheal Winger
@mordof
Jan 24 2016 22:02
don't do that then..
Bar Ziony
@bartzy
Jan 24 2016 22:02
And that's why in Java, it's an extremely common practice to copy. Actually I think almost every library does that.
Micheal Winger
@mordof
Jan 24 2016 22:04
it just seems like unnecessary hand holding to me
Bar Ziony
@bartzy
Jan 24 2016 22:06
It really isn't when it comes to big libraries
Micheal Winger
@mordof
Jan 24 2016 22:08
maybe that's why i'm not a lead dev in any of the big libraries then? no idea.. i know my opinion differs from a fair amount of people, but i've never liked that aspect
Bar Ziony
@bartzy
Jan 24 2016 22:08
it causes subtle bugs...
For example, let's say you have an object that has this.point = new Point(10,50)
now you use this object's point to create a layer or whatever. This layer now has that point as an instance variable. Later on, the first object is destroyed in some way, or altered
you can't even know that sometimes
Micheal Winger
@mordof
Jan 24 2016 22:09
i do understand the bugs it can cause, and the complications that arise.. i just don't think it should be up to the library developers to "protect" any other developer who uses their library away from that
Bar Ziony
@bartzy
Jan 24 2016 22:09
they don't protect the other developers
They protect their own code
from outside intervention
Micheal Winger
@mordof
Jan 24 2016 22:10
i like the way pixi can be worked with like that
i probably wouldn't use pixi if it couldn't
Bar Ziony
@bartzy
Jan 24 2016 22:11
but PIXI does that as well, in another way
OK actually it doesn't
specifically for this.position in a DisplayObject, I mean
Micheal Winger
@mordof
Jan 24 2016 22:12
gotta run for supper - but i think it's a topic where agreeing to disagree is likely going to need to happen, lol. i don't work on public projects very much.. so my experiences are limited to those types of problems
possibly, if i worked in public projects more, i'd think differently
limited for those*
Bar Ziony
@bartzy
Jan 24 2016 22:14
Yeah of course, there's no right answer
I just know that major stuff, like Apple's frameworks, Android and stuff like that
are generally very "defensive" of their code in order to avoid these issues
cya later :)