intoxopox

Members
  • Content count

    15
  • Joined

  • Last visited

  1. boilerplate setup

    At the risk of dirtying this back-and-forth, I just wanted to say I've been enjoying the hell out of this discussion. I know all modernity screams modules over namespaces these days, and I even think I agree at the end of the day. However, I only started really learning JS and Typescript recently, having come primarily from ActionScript since its inception. With that background, I have secretly been partial to a hybrid of current module handling and namespaces. For me at least, having the library's user determine the alias rather than defaulting to a developer's root package/namespace invites confusion for multiple developers sharing code that use the same libraries. JS modules currently look not-ready-for-my-suborn-ways, with so many flavors and build dependencies, but they're getting closer for sure. Maybe it's just muscle memory, but I was quite fond of reverse domain name notation being sort of a forced rule for packaging/namespacing imports in languages like AS3. Looking forward to seeing how the dust settles... both in this thread and in future ECMAScript. As a side note, this article resonated with me: https://hackernoon.com/native-es-modules-ready-for-prime-time-87c64d294d3c
  2. Can containsPoint be moved to Container?

    Thanks again, ivan! That works great. Now I can test for pointer with just Object.keys(someContainer.trackedPointers).length.
  3. Can containsPoint be moved to Container?

    Ah... good looking out. I'll dig in later tonight. Thx!
  4. Can containsPoint be moved to Container?

    I see. That makes sense. My particular use case is I have containers which have both sprite and graphic children. I was hoping to use something like containsPoint to see if mouse was still over any of the children. Further, I had abstracted this call in such a way that sometimes it would be called on one of the children and sometimes it would be called on the parent container. I can work around this ok, but just thought I had found a good reason to move the call to container and perhaps, in doing so, slightly improve the polymorphism. However, I see what you're saying.
  5. Can containsPoint be moved to Container?

    Any thoughts on this request? I realize the implementation is different on graphics vs sprite-based, but it would be rad to have the method in Container for better polymorphism, and have it call the corrisponding implementation on graphic and sprite children.
  6. Is there a good reason containsPoint method couldn't be moved down to Container and examine children, since it's already on Graphics, Sprite, Mesh, etc?
  7. using webcam with pixi.js

    Did you ever have any success with getting webcam data?
  8. How to add a shadow?

    Gotta say... I hope it comes back a lot sooner than that.
  9. How about set a hitArea for the root container and listen for mouseleave or pointerleave.
  10. pixi.js version 4.0.0-rc1 is out

    Ah! https://github.com/jumpinjackie/jsdoc-typescript-plugin
  11. pixi.js version 4.0.0-rc1 is out

    Good question. New enough to Typescript (just over a month), I'm not really sure.
  12. pixi.js version 4.0.0-rc1 is out

    When do you guys think you'll have typescript definitions for v4? Not until official release, I suspect... but thought Id check.
  13. mouse interactivity ignores lines

    For a line, using a rectangle is reasonable, but what about for thick complex curves? While they can be broken into multiple polygon fills, doing so comes at a considerable cost compared to just using quad and cubic curves.
  14. mouse interactivity ignores lines

    If I create a Graphics object and draw just a thick line or curve in it, I can't seem to get any recognition of mouse interactions on that Graphic. Seems I have to use a beginFill and draw out a shape before mouse will interact. Anyone else experience this? Is there a work-around?