themoonrat

Members
  • Content Count

    242
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by themoonrat

  1. Yeah, the hosting of pixi versions is down atm
  2. Yeps, thanks! We're aware; one of the reasons the v5 release has been delayed a little! Hopefully fixed soon and a new era can begin
  3. Hi all Just to let you know that we've moved examples for PixiJS version 4 to https://pixijs.io/examples-v4/ and the regular examples page at https://pixijs.io/examples/ are targeting the upcoming PixiJS version 5, using the latest APIs rather than deprecated version (`Sprite.from` rather than `Sprite.fromImage`, for example). All v5 examples are also in ES6+ now. If you land at the wrong one, don't worry, the menu on the left lets you easily switch between the 2 pages. The main point of this post; what examples would you like to see added? Is there anything you found tricky when you first started using PixiJS? Any techniques you saw posted on here that you think should get better visibility? Please let us know what you'd like to see, and we'll have a good pool of ideas to start with. And if you feel like helping us out by creating some examples for us, please go for it! Thanks
  4. I'd also say, in v5, to get the zIndex property to work, you need to set `PIXI.settings.SORTABLE_CHILDREN=true` before creating your renderer. Now the libs will automatically sorted by zIndex value on each update. But how you get those zIndex values is left up to you; I would write code that rather than does your own sorting, seeing if you could write a function that updates each objects zIndex and then see if the v5 sorting can handle it from there. Otherwise, Exca's post above is better than anything I could write on the subject!
  5. Hi @5neia_opo2@google-mail.ooo I'm sorry that you feel you are being bullied. I can understand how you may feel that way after he asked to ban you, but I don't think this is a case of bullying, just frustration boiling over. This is a forum where people give up their free time to help fellow users of the PixiJS library. And PixiJS is created by volunteers who are giving up even more time to develop an awesome open source renderer that anyone can use for free. We more than welcome the questions you have been asking, and you have been getting helpful answers, but you are coming across in a negative way at times. We're trying to help, but you are often disparaging about the library. That's where part of botmaster's frustrations come from; you are new to using PixiJS, it's unfamiliar to you, it's different to what you have used before, and as all libraries do, has it's own quirks / deficiencies. (ps. we love people to contribute PRs to help improve things!). We're a small team trying to help, but in your posts you often don't come across particularly grateful for what is being offered. And when we're trying to offer something for free, to be told it's no good isn't a nice feeling! Some examples of these comments are: We don't want to get into banning people here if we can help it. You have questions, and we're happy to help here! Just please think about how you are wording your thoughts when posting on here. Even if the mind is frustrated, try to write calmly! And I'm sure that this post here conveys @botmaster's frustrations, and would apologise for asking you to get banned as you understand where his frustrations may have stemmed from. We want this to be a happy helpful place!
  6. Pr would be welcome for v5
  7. That setting adjusts the delta emitted from the ticker, not how often the ticker is emitted. console.log that delta value and you'll see a difference. If the setting is left alone, if requestAnimationFrame can emit 60 times a second, that delta will come out as `1` as it's hitting it's target.
  8. I think what Ivan is trying to explain is that yes, there are events for a child being added to a parent, but it's just that. If you have a parent, and then a child, and a child of the child.... there's a link between the child and child of the child, but no link between the parent and the child of the child. If the child got added to parent2 instead, the child of the child wouldn't know about it. Which is fine for most occasions and usages. As Ivan said, the v5 solution is a basic way to automatically sort a container and it's children, and nothing else. But his pixi-layers solution is far more advanced and gives access to more powerful features at the expense of changing your usual thoughts on the order of rendering. An easy example is imagine you've got players who control tanks in a multiplier game, and each tank has the players name above it so you know who you are battling. Logically, you'd think of a container, that has the tank as a sprite, and a player name as a piece of text. This sounds fine, but tank #2 comes along, has been added to the world container second, so appears over the top of the first tank AND appears over it's player name too! So you want ALL player names to appear over ALL tanks. Ok, well you've got a choice... either player names all sit on a different container separate to all tanks, so you now have to move the names in sync with the sprite, with no parent / child relationship at all.... or you use something like pixi-layers which can let you keep the sprite and player names logically together, but it does magic in the background to change the rendering order away from the default simple render tree. So that also helps explain why it's not been included before. It's easy to polyfill in your own simple solution, and requirements on what the solution should be differs. How advanced do you make this? pixi-layers solves real problems but can only solve them by breaking the usual easy-to-understand rendering order. Which then effects easy-to-understand interaction order, then filter order... and so on! So yeah, I based a simple v5 solution on ivan's advice for v4, which just sorts containers automatically in a way that could already done, and it's opt-in, to hopefully not effect any previous custom solutions.
  9. For picking the better GPU, there is an option called powerPreference Set it to high-performance and the browser will take that as a hint to use the best GPU available. https://pixijs.download/v4.8.7/docs/PIXI.html#.autoDetectRenderer
  10. True. I'd love someone to create a PR that would create a more realistic scene in all renderers to use as a comparison. As it is, each one has strengths in different areas. The only consistent thing I've found is that when adding new objects to a scene, phaser 3 is noticeably a lot slower. Dunno why 😕
  11. V5 of Pixi specifically adds better batching for complex graphics, and allowing batching when swapping from graphics to sprites.
  12. Pixi 5 alpha I should remove really. Webgl Anti aliasing is accidentally always on, so kills performance. Dev is v5 with that fixed!
  13. Good luck! Don't use ruby at all, but it'll be great seeing the results of all your hard work
  14. Imagine you create a game at 1920x1080, which runs fine on most devices, but you have some older ones you want to support that aren't performing up to scratch and never will. Ok, well, set the resolution to 0.5, which can also trigger the loader to use @0.5 textures you have provided, and very quickly you have something that can run on lower performing devices. And then you're game gets picked up and you're going to a show to put your game on a big screen. Set the resolution to 2, which can also trigger the loader to use @2 assets provided, and you now have a 4k native resolution game with minimum fuss. It's also possible, with a small amount of hackery, to change this resolution property dynamically on the renderer. A lot of video games do that these these days ... they have a target resolution, but will lower it if performance starts to suffer to get the fps back up. And once the fps comes up and is stable, it'll raise the resolution back to it's target again.
  15. Ahh. I've no idea why there would be the slow down tbh. @ivan.popelyshev?
  16. Use 'dev' for comparing v5 performance, the alpha tag had AA enabled accidentally. Might remove that alpha tag for that reason
  17. I created a tool that allows direct engine to engine and version to version performance comparison: https://github.com/themoonrat/webgl-benchmark
  18. You just always get a sawtooth memory visual using Dev tools. That's how Chrome had always been with rAF even with an empty function. I wouldn't worry about it.
  19. For WebAudio, the only way to avoid decoding the file is to not have it encoded, so have it as a wav. But your file will be huge so that probably isn't practical on the web. Otherwise why not use an audio tag just for the background music only? Audio tags can play without having to download the full file first...
  20. https://github.com/themoonrat/webgl-benchmark Lets you compare different scene setups in different versions of pixi and phaser Useful to compare different engine performance. To compare different version performance. And to compare different scene setup performance. Ie. compare the speed for 'Multiple Textures' for Pixi v3 vs v4. Multi texturing was added for v4, so you'll see a large speed increase. Likewise compare 'Graphics: Complex' from v4 to v5 (dev is best); a lot of work into batching Graphics shows clear performance benefits. But then on the same hand on a modern Pixi version and test 'Sprites: Multiple Textures' vs 'SpriteSheet', and you'll see speed improvements on devices with less than 16 texture units; showing benefit of keeping sprites onto a single texture. Any requests, please raise issues
  21. @jjwallace I have a new project setup at https://github.com/themoonrat/webgl-benchmark that lets you compare different scene setups in different versions of pixi and phaser
  22. It really depends on your needs. Bitmap text is faster to render, yes, because normal text requires generating and uploading a new texture to the GPU each time it changes. And every piece of text also requires it's own texture, which can mount up. But, as you say, normal Text gives you much more flexibility at runtime to create different styled text. And if you're supporting other languages, much easier to use normal Text than trying to create bitmap fonts for every character set..... So they both have strengths and weaknesses, so there is never a 'this is always the best one to use in all scenarios'. You can mitigate a Text weaknesses, for example, by generating all of the Text textures up front, avoiding the slowness of generating them as they're being rendered for the first time. It uses more memory, but maybe that's an acceptable trade off? Or have some fancy code so that if you have the same word and style in 2 places, you don't have 2 Text objects with their own textures, but they share the 1 texture? Or use textures from Text to create a dynamic atlas, which pixi-ui uses I believe. a rapidly updating high score object might rule out normal Text because the rapidly regeneration of the texture may cause performance issues. Or maybe not. Profile your own use case
  23. It can be useful to have multiple loaders, as the loader pixi uses will not let you add resources to load whilst it is currently in it's loading process. So imagine you were were dynamically loading in assets as required in a game, you might set some assets loading, but then you reach another part of the game and want those loaded too. The first loader is in progress and still hasn't finished yet, so you need another one to load this second batch. Rather than having all load queues that are equal, perhaps you have a pool of loaders, some are high priority "must load asap" with a high concurrency, and maybe you have a pool of loaders that deal with low priority 'trickle' loading with a concurrency of 1?
  24. So, there are 2 methods to have adaptive quality; one is to dynamically change things at runtime depending on performance, and the other is to figure out a quality before the app even loads to adapt. At runtime, then yes, you are measuring fps. But you have to record a rolling average, really. If after reading the fps over the last 5 seconds, the frame rate had a min of 20 and a max of 30...then it's clear there is a persistent issue in performance, and maybe you could adjust the resolution of the app on the fly, or not play certain particle effects / filters. Just a one off measurement might be you getting unlucky during garbage collection or something. But also make sure make sure that you're measuring at the right time. Don't measure whilst loading assets; download assets and uploading textures to the gpu can cause stutters on any device, so wait to measuring until you know the device has it's best chances of displaying good performance. Figuring out the quality before the app loads usually gives the best user experience.... and you have 2 ways of this route. The first is as ivan suggested and give the user the option to choose. The other is to try and detect the capabilities of the device and change settings based on that. At a basic level, if the device can only support the canvas renderer, you know you've got a low quality device on your hands. You could detect browser versions. You could detect WebGL capabilities: http://webglreport.com/ is a super useful website in that respect. Compare the hardware you have via that website; find out what differences there are in the hardware that runs your app well and the hardware that runs your app less well. For example, the lower end hardware may support less texture units, or may not support anti-aliasing.