• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by themoonrat

  1. 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: - 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: 2. Take a look at our wiki, it covers gotchas / migration guide / advice: 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: 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
  2. 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!
  3. 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 object and you'll see all of the data that exists for that event, including information to distinguish between different presses
  4. It applies to the base texture
  5. Top result!
  6. 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
  7. 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)
  8. 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);
  9. 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
  10. 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
  11. Take a look through for other webgl parameters you could use to distinguish device performance. I know that older hardware on mobile returns 0 for SAMPLES for example
  12. 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
  13. Perhaps, yeah 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
  14. 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";
  15. 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
  16. @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
  17. Look at the data that's supplied in that event, just like the event data of any interaction callback. It's of type
  18. Events on renderer.plugins.interaction cover the whole screen renderer.plugins.interaction.on( 'pointerdown', () => { console.log('pointerdown') } );
  19. Create your text object once, and update it via .text = const title = new PIXI.Text('hi'); title.text = 'Changed text';
  20. the renderer hasn't actually rendered anything yet. Force the renderer to render what you've put on screen first via app.render();
  21. So the rational behind the browser vendors is that a touchstart could be the start of scrolling the page, rather than interacting on screen. They want certain api's to be unlocked on a guaranteed 'user has touched the screen for the sake of trying to press something'. By using 'touchend', what they can do is only unlock the api if there is a touchstart following by a touchend. If there is a touchstart, then some scrolling, then a touchend, then they know not to unlock the api's on the touchend; the user was scrolling, not interacting. (Apple changing unlocking audio from touchstart to touchend from ios9 to ios10 caused us to have to re-release all of our games to get sound working again. grrrrrr)
  22. Try fullscreenbutton.on('click', function(e){ fullscreen(); } Looked at my code for this and indeed it seems click is the only event that works for full screen api across android and windows phones. Well, actually, my code sets up listeners for both touchend and click, but not sure if that was overkill on my part or attempting to pre-empt a future browser manufacturer decision!
  23. Despite adding support for pointer events in the latest Chrome... they haven't made them act as a user event that can unlock other apis, like webaudio and fullscreen. To unlock these APIs, you'll need to explicitly use 'touchstart'
  24. Indeed, RequestAnimationFrame will stop when the the browser things it's not worth rendering anything to the window because it's minimized. There is however the Page Visibility API to detect this event ( - This could be useful to pause sounds when you know the game has become not visible, or to put up a pause menu if you wish