xerver

Members
  • Content count

    1,417
  • Joined

  • Last visited

  • Days Won

    12

xerver last won the day on September 16 2016

xerver had the most liked content!

2 Followers

About xerver

  • Rank
    Pixi.js Moderator
  • Birthday

Contact Methods

  • Website URL
    http://github.com/englercj
  • Twitter
    rolnaaba

Profile Information

  • Gender
    Male
  • Location
    USA

Recent Profile Visitors

1,324 profile views
  1. IF the player can change their client to affect the outcome of your multiplayer game you may want to rearchitect. Not only do you have to assume all clients are malicious, but its JS and even easier to modify; and there is nothing you can do to stop people.
  2. Because they are different urls, one is "root domain -> resources -> ..." the other is "current url -> resources -> ...".
  3. Remember these are URLs, not file paths.
  4. There is no such thing as a library that requires TypeScript, not sure what would give you that impression. In what way does it not work? Have you tried posting an issue on the repo? In what way does it not work? Have you tried posting an issue on the repo? TypeScript compiles to JS, no library *requires* TypeScript. Even the main field points to the built file.
  5. I'm aware. Your asking "How would I implement this", and I am asking "Have you looked at how that one is implemented".
  6. Have you looked at the scale manager in Phaser? I would start there.
  7. Do you think you can build a more constrained example? I'm having a hard time tracking through this since it is minified, and has a lot of irrelevant stuff. Just something that is purely pixi and only renders enough to get the error would be very helpful.
  8. Please share a running example that reproduces the bug, as well as your browser/os information.
  9. WebGL draws to a canvas, nearly all Canvas APIs still work even when you are using WebGL. It is the CanvasContextRendering2D APIs that you can't use.
  10. Ah this was a different bug altogether, didn't notice since it was on the old closed issue. Should be fixed now in the latest dev of pixi (was fixed in v2.0.6 of resource-loader).
  11. It is fixed, make sure you are on the latest version of pixi. There is not currently a way to tell what the number of resources will be before loading, because we can't know how many there are until we load some. For example, that json file could be just 1 resource (just the json), or 2 resources (json + image). No way to know until after we load the json. That is why the progress event should let you know what the progress is, so you can do a loading bar based on that number and not worry about trying to calculate based on number of resources.
  12. Because 2 assets are loaded, the json manifest and the image it references. PIXI has a middleware parser that parses the json, sees it is a spritesheet, and adds the image it references to be loaded as well. Then, once loaded it creates textures for all the different frames of the sheet.
  13. That tree at the bottom labeled "Retainers" is telling you what is retaining that object. Hard to say with what you just described to me there, but you should be calling "this._scene.destroy(true)" most likely. Because otherwise references will likely be kept around.
  14. Nope, welcome to dynamic languages. It is up to the VM to garbage collect stuff when it feels it is appropriate. All you can do is lose references so it has the ability to cleanup, but when it cleans up is 100% up to the VM. If you click the GC button in dev tools and it suddenly frees a ton of memory, then it is just because the VM decided not to free that memory and instead reserve it for future use. This is not uncommon. Yup, the important part of the Heap Snapshot isn't so much large allocations as it is leaks. Specifically things highlighted in yellow, or things between two different snapshots that shouldn't be there anymore after the first one. For example, load a map and perform a snapshot, then do some action in your game that should clear memory and take another snapshot. See anything hanging around when it shouldn't?
  15. If you can support having all that memory allocated, then chrome will just leave it there because it doesn't see a reason not to keep using it for other things (allocation/deallocation are expensive operations). Best you can do is destroy (clears our references and GPU memory) and then lose all of your references. You can also do a memory profile and see if you have any references laying around that is keeping that image alive longer than you think it is (not resetting the loader perhaps?).