• Content count

  • Joined

  • Last visited

About themoonrat

  • Rank
    Advanced Member
  • Birthday 11/25/1982

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  • Location

Recent Profile Visitors

1,315 profile views
  1. 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!
  2. Need Android Muti-Touch Example...

    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
  3. Anti-aliasing question

    It applies to the base texture
  4. Particles Demo? - Also Do They Only Work In WebGL? Top result!
  5. How To Detect Pressing & Holding Screen On Android?

    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
  6. Load images individually

    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)
  7. Ticker.remove function not behaving as expected

    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);
  8. Load images individually

    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
  9. Preparing the Sprite-sheet

    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
  10. low end devices

    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
  11. On Android Must Tap Twice To Press Button?

    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
  12. Dom element vs PIXI.Text performance

    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
  13. Dom element vs PIXI.Text performance

    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";
  14. Dom element vs PIXI.Text performance

    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
  15. Dom element vs PIXI.Text performance

    @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