xerver

Members
  • Content Count

    1598
  • Joined

  • Last visited

  • Days Won

    15

Everything posted by xerver

  1. As Exca mentioned this is an actual browser limitation. There is a limit to the number of WebGL contexts you are allowed to create in a single page. The actual number depends on your environment and browser. No, one canvas has 1 renderer.
  2. Do you have a running example we can debug?
  3. A running playground that reproduces this problem would be really helpful for trying to track down what is going on here. You can choose the pixi version using the "settings" button to get your exact version.
  4. No bans are happening here (yet). @5neia_opo2@google-mail.ooo, try to understand the frustration people are experiencing. A new user came to the forum and in nearly every post they made trashed the project they were asking about. A lot of people here put in a lot of time and effort to not only to develop the project, but answer questions here as well. I was definitely frustrated reading your responses as someone who has put 6+ years of their life into this project. @botmaster did a poor job of handling that situation, but has apologized and I'm sure will do better in the future, as will you as well. Let's all be adults about this, acknowledge we did something wrong, and move on. @5neia_opo2@google-mail.ooo you are free to ask any question you need help with, but I definitely recommend reading through some tutorials, the examples, and checking the API docs before asking questions. It will often lead to you finding the answer yourself, and there will be less fatigue for the people answering here on the forum. I'd also recommend you approach things you don't understand, or decisions you disagree with, with a more open mind. Try to learn and grow the new library, not all libraries are alike and different problem spaces call for different solutions. Having a bad attitude is a good way to earn ill-will in the community and you may no longer get the help you expect if you are ungracious about it. When you find inconsistencies, or things you think should work differently, then change it! Pixi.js is an open source library built by the community. Everyone gets a chance to make the library better by contributing to it. The best way to get problems you have fixed, are to fix them yourself.
  5. A description of how to run it locally is in the readme: https://github.com/englercj/playground#usage
  6. Then you should make those changes and PR them to the main repo, not deploy a separate parallel instance. I'd love to integrate the ability to handle l10n! Setting up and running your own instance is not something you need to do, especially if your not familiar with managing deployments like this. If you insist: Everything you would need to know about setting up a server to run the app on is here: https://github.com/englercj/playground/blob/9267471c869d1610339e8c7a175d322453b69dbd/server/droplet-setup.sh Environment configuration and how that gets setup is here: https://github.com/englercj/playground/blob/9267471c869d1610339e8c7a175d322453b69dbd/server/src/config.ts
  7. Hello, npm contains all the dependencies needed to build and run locally. To run on the server in "production" mode there is a lot more involved (MySQL and CloudFlare integration for example). I have automated scripts for setting up a server, but you still need to build them yourself and make all the configuration. Why are you trying to publish a separate version of the playground app? If you are trying to share a playground with someone, just make it and save it on the live site: https://www.pixiplayground.com/#/edit
  8. Are you encountering a performance issue with the method you are using?
  9. If you are using ES6 then extend the class using ES6: export class CustomSpriteClass extends PIXI.Sprite { constructor(imageURL) { super(Texture.fromImage(imageURL)); } } If you have to use ES5 the proper way to extend a constructor is: function CustomSpriteClass(imageURL) { PIXI.Sprite.call(this, Texture.fromImage(imageURL)); } CustomSpriteClass.prototype = Object.create(PIXI.Sprite.prototype); CustomSpriteClass.prototype.constructor = CustomSpriteClass;
  10. I think you are looking for getBounds(): http://pixijs.download/release/docs/PIXI.Container.html#getBounds
  11. The correct way to implement this would be through a proposed "subresource options" feature (https://github.com/englercj/resource-loader/issues/98) and the addition of a Resource-specific option for appending a query string. If you have better ideas for how this should work, please add them to: https://github.com/englercj/resource-loader/issues As always PRs are welcome for additional features that make your life easier.
  12. http://pixijs.io/examples/#/basics/render-texture.js For next time, prefer opening a new thread to reviving a 3 year old one
  13. Conditionally load the pixi.js file and the code that draws your graphics based on some JS on your page that does your detection?
  14. The loader only sends an XHR request for font files. Without a repro page, I am unable to comment on what is happening.
  15. Yeah the other process would write the files and the main process will pick them up. Pixi doesn't natively support dds, you will need to use a plugin (like pixi-compressed-textures). I have no recommendations for DDS serializers in JS, or rasterizers.
  16. You can store them as an uncompressed bitmap, but PNG is completely fine. The decode time from PNG -> bitmap is usually OK. If you want to avoid that time you can store them as dds or something similar to get some compression, but skip the decoding step that the browser would have to perform. The performance benefit you get is just being able to skip your rasterization step. I bet that PNG -> bitmap by the browser is much faster than your SVG -> bitmap raster.
  17. I would build the images on a separate thread and write them to disk, then the main thread loads them from disk. That way next time you launch you don't need to convert them again, just load the already converted files from disk. If possible, you can even do this at build time and ship the images in the built format.
  18. No. We don't upload the texture until the texture has been completely downloaded and we need to render a sprite that uses it (so it is in the stage). The first time we encounter a new texture on a render pass is when it will get uploaded, there is no preallocation that happens. You can upload it manually if you need to like Ivan mentioned.
  19. I threw a simple palette example together that hopefully can help you track down your issue: https://www.pixiplayground.com/#/edit/cJY98QTkz7yv7QQVp9jRN I create the map texture with a utility I wrote a long time ago, that I'm not even sure if it works anymore: https://github.com/englercj/paletter The original image, map image, and palette image that I use for the demo are in that repository as well.
  20. You can draw 1 tileable graphics object to a RenderTexture and use that in a TileSprite.
  21. There is no built-in way to do this, you would have to manually handle the input and draw a highlight. Or use DOM.
  22. Best place to start is the profiler, what is taking 15ms? Can you make a playground example?
  23. Fair enough, I would still remove the mix of es5 functions (.prototype.func = function () {}) and just use es6 functions. But it makes sense why you are using an IIFE. Just so you know, if you use a module system like CommonJS (require('...')) or ES6 Modules (import from '...') then the bundler (Webpack, Rollup, etc) will usually wrap each of the modules in an IIFE for you. If you are just concatinating js files together then you should keep the IIFE.
  24. To answer your original question: Yes, adding/removing all your sprites every frame is expensive. Instead, track state and only change the minimum amount you have to. If a sprite exists between two frames, then it shouldn't be removed then added again. Ivan's example was to show you he isn't changing the scene tree at all unless he needs to. When something dies, it gets removed. When it is new, it gets added. Otherwise, no change.
  25. Have you profiled it? Without profiling, you are just guessing as to what is taking your time. I seriously doubt that object property lookup is your bottleneck.