• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by themoonrat

  1. 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
  2. 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";
  3. 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
  4. @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
  5. Look at the data that's supplied in that event, just like the event data of any interaction callback. It's of type
  6. Events on renderer.plugins.interaction cover the whole screen renderer.plugins.interaction.on( 'pointerdown', () => { console.log('pointerdown') } );
  7. Create your text object once, and update it via .text = const title = new PIXI.Text('hi'); title.text = 'Changed text';
  8. the renderer hasn't actually rendered anything yet. Force the renderer to render what you've put on screen first via app.render();
  9. 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)
  10. 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!
  11. 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'
  12. 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
  14. No. You'll have to implement those yourself via tweening the alpha property of containers.
  15. Ok, there's a couple of crazy things there In input.js, you are joining the pointerdown and pointerup event EVERY FRAME. You only join the event once. In initialize.js, the function you are passing does not exist in that file scope Button[index].on( 'pointerdown', onClickButton(index) ); The way you use the function callback also won't work. You need to supply a reference to a function, or an anonymous function, as that parameter. You are actually trying to call that function there and then
  16. Use a breakpoint and look within the event object after adding a pointermove event renderer.plugins.interaction.on( 'pointermove', ( event ) => { console.log( event ) } ); All the info you need is in there
  17. renderer.plugins.interaction.on( 'pointerdown', ( event ) => { console.log( event ) } );
  18. Take a look at the examples page which demonstrates usage
  19. There is a big performance advantage to have as few images loaded and used as possible. Therefore games tend to use 'sprite/texture atlases', in which lots of individual images are combined into one big one. Then the libs can use the json data to work out which part of that big image contains the smaller image needed to be displayed. Don't worry, it's not hand done, there are lots of tools to generate this all for you, like TexturePacker. Pixi can use the json format exported by that tool natively.
  20. Check the official pixi wiki page on github: Most specifically: The main thing tho; profile profile profile! Use Google Chrome profiler to see where performance is being lost. It's very very hard answer questions of performance in an online forum because every game and every scene is different. Only you can find out where things are slow by using the tools available
  21. @JeZxLee you are using an old version of PIXI, v4.0.0. This issue does not exist in the latest version, 4.5.3
  22. The refresh rate is the monitor will effect fps.... the browser may decide to not send a new requestAnimationFrame if the monitor won't be refreshing to display any changes
  23. The documented setting for forcing the canvas renderer works when creating a pixi application or auto detect renderer. If it's not working for you, you're not using the setting correctly!
  24. Just google "Why is WebGL faster than Canvas" WebGL gives PIXI direct access to the GPU, and as such it can choose how to batch up certain commands for the GPU to run in an efficient manner. A simple example being, if you are drawing the same sprite over and over, you don't need to keep telling the GPU the details of the sprite every time, you just say here's your current texture, now draw here, here, here, here and here. Therefore WebGL is very very quick at drawing the same texture multiple times at once. Other tricks like masking and filters can be done totally on the GPU too. The Canvas API does not give you direct access to the GPU. You are using a general purpose simple API provided by the browser; every command you make will use some CPU to use this API, and it cannot optimize how to send the draw commands to the GPU. In the above example, each draw call is it's own thing; the batching up of super fast drawing of the same texture cannot occur. In a large generalization, the way to get performance up in the Canvas renderer is to make less draw calls. So, your game WILL ALWAYS be slower in Canvas renderer than WebGL renderer, and there's nothing you can do about that. It's not unreasonable to have a 2 code paths on occasions, one for clients using WebGL, and one for using Canvas. The WebGL version has all the bells and whistles and is the actual true vision of the game. Canvas mode (for me at least) is 'let the player play and experience the game', which comes at the cost of lower resolution textures, lower resolution game, less (or no) fancy effects. Other io games are doing this because they're written their games to perform well on the Canvas renderer. It's like making a game for a console. If you write a game targetted at a PS4, then run it on a PS3, then it's not going to perform well. You often have to tweak the game vision to match the hardware you are targetting.