themoonrat

Members
  • Content Count

    254
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by themoonrat

  1. Good luck! Don't use ruby at all, but it'll be great seeing the results of all your hard work
  2. 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.
  3. Ahh. I've no idea why there would be the slow down tbh. @ivan.popelyshev?
  4. Use 'dev' for comparing v5 performance, the alpha tag had AA enabled accidentally. Might remove that alpha tag for that reason
  5. I created a tool that allows direct engine to engine and version to version performance comparison: https://github.com/themoonrat/webgl-benchmark
  6. 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.
  7. 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...
  8. 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
  9. @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
  10. 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
  11. 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?
  12. 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.
  13. Is it possible to set up a fiddle to demonstrate this? I have a large range of devices available I could set on tomorrow to see if there's a difference between different ios versions
  14. There is something bizarre in your setup that isn't quite right. Because, for you, PIXI is just entirely broken. But it's not broken for anyone else I've just got the testers here to test on IE and Firefox on Windows 7, IE and Firefox on Windows 10, Safari on a mac... and it all works. And they all work because they do not have 'window.ontouchstart', and thus 'this.supportsTouchEvents' becomes false, thus there is no issue on the if statement in question. So the first port of all... load up a fresh instance of IE, go to about:blank, and then in the console, type in 'window.ontouchstart'. I'd expect it to return 'undefined' If that is the same for you, the question becomes... why does your setup have 'ontouchstart' defined for ALL browsers, no matter what, when browser themselves do not have that property? Which makes me think somewhere in your code base is adding it. Perhaps a polyfill?
  15. @botmaster Could you create a little jsfiddle please demonstrating the error you are describing, and I'll take a look. Games I make using PIXI are tested against pretty much everything, and we've never seen anything like this before. It'd also be useful to know what kind of desktop device you are playing on.... or does it go wrong on a range of devices? Thanks!
  16. https://chrome.google.com/webstore/detail/spectorjs/denbgaamihkadbghdceggmchnflmhpmk?hl=en is a great extension to analyse what WebGL calls are being made
  17. Also for 2. I wouldn't just link devicePixelRatio to the resolution part of PIXI. Otherwise you get mobile devices trying to render at 4k or over... which is just silly. By all means, adjust resolution based on device, but I'd pick a few resolutions, and select which one to use based on inspecting the device To change resolution of the renderer dynamically, you can use code like this const oldResolution = renderer.resolution; renderer.plugins.interaction.resolution = newResolution; if ( renderer.gl ) ) { renderer.resolution = renderer.rootRenderTarget.resolution = newResolution; } else { renderer.resolution = renderer.rootResolution = newResolution; } renderer.resize( renderer.width / oldResolution, renderer.height / oldResolution );
  18. If you wanted to go down that route, you can also do const prettyImage = new PIXI.Sprite(); const constructorName = prettyImage.constructor.name; // will return 'Sprite' https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/name
  19. Both are great options! The main advantage of Howler is it's wider use. I use it, and love it, and feel more secure in using it because so many devs do too. The main downside is fitting it into the Pixi loading process. Even if you download audio as a blob, you still need to account in your preloading process for passing it to Howler for it to be decoded. The main advantage for Pixi Sound is that it covers this integration for you. In production code, it's easier to get up and running. And the syntax and use is all very familiar because it was made by a Pixi Dev. But that's not saying Pixi Sound is not reliable, it is! And it's not saying Howler is hard to use... it really isn't. Both are great options with active and receptive maintainers.
  20. 1. I would use m4a as primary choice, and off as fallback. m4a has the same compatibility range on browsers as mp3, but sounds better for the same file size, and loops better for background music. ogg is the fallback for the uncommon occasion m4a isn't supported. 2. ALL mobile browsers now require a user touch to enable unlocking audio. If you have a 'touch here to continue' kinda screen after loading, that'll get you the touch you need
  21. They are popping in because the assets are loading in the background, and show when they've finished loading. To stop that effect, you should use the preloader within pixi to preload all assets (showing a loading screen perhaps) before starting the game
  22. https://github.com/pixijs/pixi-sound is made to integrate into the loader that pixi uses, and is successfully used in a number of projects. You really want to use another lib to handle sound to get web audio support at the very least. Otherwise you're setting yourself up for more issues in the future.
  23. I'd really recommend using Howler or pixi sound for audio, it'll handle this stuff for you
  24. Mobile requires a user interaction to 'unlock' audio and allow it to play
  25. The scale mode of the texture needs to be set to nearest. You can either do that on a texture by texture basis via the scaleMode property, or change the default via http://pixijs.download/dev/docs/PIXI.settings.html#.SCALE_MODE