• Content Count

  • Joined

  • Last visited


About bubamara

  • Rank
    Advanced Member

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

1857 profile views
  1. bubamara

    Low fps particles

    In fact, it is not a black part, but transparent. https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/getImageData where ImageData.data returns an array of RGBA pixels. If the particle size is 2, then 4 transparent pixels in that area, means particle if fully transparent (checking only alpha channel) and you don't want to be creating it. As for recommendations to improve performance: rule number one probably is to fake everything you can, users will not be able to tell difference anyway. Then you might read something about how WebGL works, how Pixi works. I'm pretty sure if you come back with a particular question (and maybe providing minimal code example) there are plenty of people here willing to answer it.
  2. bubamara

    Low fps particles

    I see you have optimized update loop even more, perfect. Now you can reduce amount of particles by not showing empty ones; total going from 29.000 down to ~3.400 in this case https://codepen.io/anon/pen/jRdQEo?editors=0010
  3. If you don't need gradients, there is this clever 3 sprites approach :
  4. bubamara

    Low fps particles

    Don't know why Firefox is so slow. But you could reduce number of particles shown/computed. Draw that texture to off-screen canvas, read pixels, check whether yours 2x2 particle is pure black and don't create it in that case
  5. bubamara

    Low fps particles

    Now I have noticed you have these two in ticker loop : this.app.renderer.resize(window.innerWidth, window.innerHeight); this.mouse = this.app.renderer.plugins.interaction.mouse.global; Move them out of loop and resize the app on event to keep animate() as simple as possible animate() { this.app.ticker.add(() => { stats.begin(); this.particles.forEach(p => { p.update(this.mouse); }); stats.end(); }); }
  6. bubamara

    Low fps particles

    Hmm, for me it's a lot faster on Chrome (both Mac & Win), not so visible speed gain on Safari/Mac. On the other hand you're rendering ±100k sprites... edit: added screens
  7. bubamara

    Low fps particles

    Looks like your update() method could be optimized. Replacing painfully slow Math.hypot with : const distance = Math.sqrt(distanceX * distanceX + distanceY * distanceY); speeds up things dramatically
  8. ogg, mp3, m4a are file formats. What you should use is Howler library (for example) to play them in your game : https://github.com/goldfire/howler.js/ https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API
  9. simplify the problem - create hidden collision circle for player's container and hit test it against platforms; players will not be able spot difference anyway
  10. @komali2 https://github.com/pixijs/pixi-spine/blob/master/examples/hack_texture.md
  11. Sorry, I should have been clearer : it depends on your use case and Pixi version. For example if you are using Pixi 4.x and mixing up NineSlicePlane with Sprites, then above mentioned Sprite-Sprite approach should be noticeably faster. Pixi 5.x can batch mesh (NineSlice) with Sprite, thus making speed difference less visible. On the other hand Pixi 4 seems to have better raw performance than v5, feel free to compare yourself : https://themoonrat.github.io/webgl-benchmark/ And when you have mentioned that you are updating them often, then it's another reason to try pure sprites approach. Anyway, would love to hear your conclusion if you find a time to compare :)
  12. sprite with another slightly smaller sprite as it's child
  13. I was comparing all 3 - dev, master & alpha
  14. @themoonrat it is pretty much expected Pixi to be a lot faster than Phaser2 and taking advantage over Phaser3 when it comes to sprite+graphics batching. But I'm seeing a huge slowdown with BitmapText rendering, while Phaser3 is rock solid at 60fps. 10000 instances, Pixi 3.0.11 - ~58FPS, 4.0.3 - ~43fps, 4.8.5 - ~40fps, 5.0.0-alpha.3 ~38fps Why is that? Is it caused by trade-off between raw performance and more complex batching (closer thing to real life usage) in v5?