themoonrat

Members
  • Content Count

    254
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by themoonrat

  1. Even if your textures are created dynamically at runtime, when you convert them to a texture, you can scale that generated texture down. ```const texture = renderer.generateTexture( displayObject, 0, 0.5 );``` for example will create that texture at half the resolution Looking at your render tree (using pixi-inspector and PIXI.utils.BaseTextureCache in the console); because of all of this generated sprites, you're missing out on one of the tricks that makes WebGL so fast; rendering sprites from the same base texture. In WebGL, each time you change the baseTexture that the renderer has to render from, there is a slight penalty. If all images are from just a few base textures, then this penalty goes away. Each generate texture you're creating is from a different base canvas... so the optimisations that allows crazy levels of bunnies in the famous bunnymark can't occur in your game. Is there a reason you have to generate the assets in game? If you _have_ to, then generate them all into one display object, convert that to a base texture and manually creating your own Textures from that?
  2. There is no support for word wrapping for CJK languages (https://en.wikipedia.org/wiki/CJK_characters) - Boo In any case, for these language what is _actually_ required is word wrap but with break words enabled; there are no spaces in CJK text, and word wrap usually just finds spaces in text. Break words allows word wrap to work without waiting for spaces. http://pixijs.download/dev/docs/PIXI.TextStyle.html#breakWords - Yay However it's not quite as simple as enabling break words, as there are rules in place as to which characters are allowed to be broken and which aren't - https://en.wikipedia.org/wiki/Line_breaking_rules_in_East_Asian_languages - Boo So you'll need to code your own custom solution at around this line: https://github.com/pixijs/pixi.js/blob/dev/src/core/text/TextMetrics.js#L122 - that checks the text wanting to be broken up to see if the rules allow for the breaking up of characters or not.
  3. As a basic 'is this mobile or desktop' - https://github.com/kaimallea/isMobile is a decent lib which Pixi uses internally. But a better option than just 'mobile or desktop' is to detect some device capabilities. At a base level 'do you support WebGL'. If not, set the lowest settings due to canvas fallback! But if it does support WebGL, you can query the hardware has to what is supported. Based off the official 'is webgl supported code' from https://github.com/pixijs/pixi.js/blob/dev/src/core/utils/index.js#L295 .... imagine i'm inside that 'if ( gl ) {' statement if ( gl.getParameter( gl.SAMPLES ) ) { const maxSamples = gl.getParameter( gl.SAMPLES ); } Now, 'samples' can equate to 'can I do multi-sampling anti-alising, and if so, how many samples can I do. Older device hardware won't support this, so will have a value as 0... whereas modern devices do. https://webglstats.com/ is a great website to show the available parameters and the stats for what the typical results. So in the above example, I could say "Well, if you support less than 4 samples, that's the lowest 13% performing of devices, you're all low quality". You can do this for a number of parameters, like texture units available, max texture size supported etc. http://webglreport.com/ Is another useful website to get that kinda report on the hardware you are running. So if a user has a specific performance issue, send them there and see if you can lower quality according something their hardware doesn't support. As for how to degrade quality, the 2 things that really effect performance and are easy to change are build time are supply lower resolution assets to lesser quality devices, and lowering the rendering resolution for lesser quality devices. Beyond that you're looking at profiling your code on lesser quality devices to see where the bottleneck is. WebGL filters, for example, can often be a good candidate to remove on lower quality devices that still support WebGL
  4. The actual renderers are the canvas and webgl, which you are free to create directly, but autoDetectRenderer is usually preferred as it favours creating the webgl renderer (much faster) but automatically falls back to canvas if webgl isn't supported. You'd only have to write this fallback yourself anyway. The Application method is just a helper class that uses autoDetectRenderer in the background, and provides commonly required basic functionality, like access to a ticker, and getters for the renderer and view. If you don't want to use it, fine We've found it very useful at pixi for creating the examples, as it handles the common boilerplate code, leaving just the example code we want to show off
  5. The doc with a single options object is the correct way going forward
  6. 1. I don't think there is a full list of changes from latest v3 to latest v4. There's a changelog of each individual release: https://github.com/pixijs/pixi.js/releases - You could go back from the beginning of the first v4 release onwards, but I'm afraid that's as close as exists as far as I am aware. Multi-texture sprite batching is the big potential performance gain with v4 over v3. The deprecation file will help to see any API changes: https://github.com/pixijs/pixi.js/blob/dev/src/deprecation.js 2. Take a look at our wiki, it covers gotchas / migration guide / advice: https://github.com/pixijs/pixi.js/wiki/ 3. If v3 gives you everything you need, and works, then it doesn't matter what new version comes out in the future... it's always going to cause a few problems because upgrading a lib usually does! There are some v5 proposals on the wiki, and some tagged issues on github: https://github.com/pixijs/pixi.js/labels/Version%3A v5.x . v4 is in pretty much maintenance mode now until v5; there won't be any big changes or breaking changes in the API. I've just shipped a game in v4 without any stability issues, but then each game uses different features, so YMMV
  7. themoonrat

    text height isue

    I think we're going to need a jsfiddle on this one, so we can debug rather than guess the common fixes for this sort of thing!
  8. It just works. If you had a pointerdown callback on your directional pad, and a pointerdown callback on your buttons, then they'll both get called even if you have the screen held down elsewhere. If you have just a pointerdown on the top level of interactionManager, then look within the event.data object and you'll see all of the data that exists for that event, including information to distinguish between different presses
  9. It applies to the base texture
  10. http://lmgtfy.com/?q=pixi+particles Top result!
  11. When the user presses down (pointerdown), you start a timeout. If the user releases (pointerup), you clear that timeout If the timeout completes, they've held down the screen
  12. you don't need to worry about the texture cache... calling destroy(true) will handle that all for you (it'll also remove that texture from the gpu memory)
  13. Since you're doing this within a class, try adding the context as a second parameter when adding and removing with the ticker. So this.game.app.ticker.add(this._someAwesomeFunction, this);
  14. You could create the sprite via PIXI.Sprite.fromImage(url); I'll create the sprite immediately, load the images from the url in the background, and as soon as the image has loaded, automatically update the texture to display it on screen. It does all the things you describe for you
  15. In texture packer, you can set the max texture atlas size. If it's creating an atlas for each image, then you probably have that setting at 2048x2048. Raise it to 4096x4096 and you'll get 4 images in per atlas. Ultimately, though, atlases are for putting lots of small individual images into one texture. You have _huge_ individual images, so not surprising atlassing isn't working out so well! With images that large, you don't have many alternate options. Raise the texture atlas size, or lower the size of the Blender output
  16. Take a look through https://webglstats.com for other webgl parameters you could use to distinguish device performance. I know that older hardware on mobile returns 0 for SAMPLES for example
  17. you can connect an android device to your pc via usb with developer mode and usb debugging enabled on your android device. Load up the game in chrome on your phone on your pc, go to chrome://inspect/#devices, and you can inspect & debug the browser like normal
  18. Perhaps, yeah https://github.com/tleunen/pixi-multistyle-text let's you do multi styled text within one text object, but you'd require multiple i think, unless you used a fixed width font
  19. You'd have a text object per column, and add text on a column by column basis, so column 1 in your example would be column1.text = "#1\n#2\n#3"; column2.text = "aabb\nとうきょう\ngood morning f";
  20. With pixi text, to get proper alignment working, you actually need to change the anchor.x value on that text object; the style alignment option only really works for multi-line text
  21. @caymanbruce I've actually come the opposite way to you; previous games used a combination of dom and canvas (no engine, just pure canvas commands), and now have everything fully on the canvas with pixi. Advantages to dom text Looks sharper Less memory usage (pixi text creates textures) Less penalty for changing text (no need to re-recreate textures!) Less rendering time in canvas renderer (in my experience; on old libs started 4 years ago making games for old devices, we found less canvas draw calls was a big factor in performance; swapping text draw calls for dom overlay helped performance) Advantages to pixi text Make text look fancier (complex gradients that work on all browsers with no hacks. With dom text, there's varying browser support with fallbacks needing to be created) Easier to move text around the screen, as well as changing it's z-index, as it is a child of on screen display objects (dom text always has to sit above everything) More accurate resizing of text (my games have to support 17 languages... so for every piece of text we need to give a max width and max height that can be in. Easy to iterate over measuring in canvas, tricky and not very accurate in dom, with hacks require to avoid dom reflows when trying to measure text) No worries about different browsers rendering things differently or in different places. Placement of text for me was important in the games, in dom, just a pixel or two difference on a small piece of text could make the difference between it looking good or not looking good. So in the new libs, we're enjoying the advantages of pixi text, with a couple of things to help mitigate the negatives; pre-creating text textures so they're not being changed in game, caching text so 2 text objects with the same style and text share the same texture, rendering text at a higher resolution to the game etc. But there are different use cases (perhaps yours) which makes going the dom route better suited for you
  22. Look at the data that's supplied in that event, just like the event data of any interaction callback. It's of type http://pixijs.download/dev/docs/PIXI.interaction.InteractionData.html
  23. Events on renderer.plugins.interaction cover the whole screen renderer.plugins.interaction.on( 'pointerdown', () => { console.log('pointerdown') } );
  24. Create your text object once, and update it via .text = const title = new PIXI.Text('hi'); title.text = 'Changed text';
  25. the renderer hasn't actually rendered anything yet. Force the renderer to render what you've put on screen first via app.render();