• 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

933 profile views
  1. Hey! First of all, be wary of GSAP unless you're willing to (or your clients are willing to) pay for a business license! Second; es6 with it's classes syntax sugar makes an oop style a lot easier. I'm fact, pixi uses that right now, with a base display object class that a container inherits from, and a sprite is a container with a texture.. etc. es6 also adds in a standard way of creating and using modules; great for splitting up code into reusable classes/utils. Essentially, you'll want to use a transpiler to let you code in the latest language features to allow support for current browsers. Babel is the best (imo) Third.... There are tool chains like webpack, gulp, browserify etc that let you help build your game. The are some templates on github you may want to take a look at, like or . They've not been updated recently, but you'll get an idea of how others structure their projects.
  2. Try adding padding to the TextStyle?
  3. Thanks for the heads up before nap time
  4. I'd see if hammer.js provides what you require
  5. The reason this occurs within PIXI and not plain canvas is due to how PIXI does Text. Essentially, because drawing text is slow, when you change text on a PIXI.Text object, it draws that out to a canvas and then treats that as a texture to use a Sprite. Rendering this sprite each time is super fast. To get the alignment, it's taking this generated texture, and aligning that to it's right edge, rather than the text. I'm guessing this texture width is going up in non even amounts each time a 0 is added, and thus you're getting this pixel different wobble. As for a solution... meh. The latest pixi has a .trim = true you can set in pixi style, which I think helps ( ) but doesn't completely solve. It's also more intensive on cpu, trimming every texture generated by the text class. As a hack, u could also set the width of the text after it has been generated. The width size of your textures go 14 / 29 / 43 / 58 / 72. If you knew for example to manually set "00" to width 28, even though it's generate it as a 29 wide pixel, that might help? Since changing values rapidly is not a great idea with text anyway, what I do for counters is either use a bitmap fixed width font, or draw out each number, save as a texture, and re-use that texture as sprites for a counter. So 0000 would use the single "0" generated texture in 4 different sprites evenly spaced apart. Now, changing numbers is just changing which texture to use, which is super fast
  6. also allows drawing a path for a tween to follow
  7. And unrelated(ish) - I always recommend creating sprites using Sprite.fromFrame() if you expect them to be preloaded. fromFrame will only look in the texture cache, and report an error if it's not found fromImage which will try to load the image if it's not in the texture cache If I know I'm preloading assets, I'd rather get an error that it doesn't exist and work out why.
  8. If you wanted to be super quick about it, you could just iterate through everything in PIXI.utils.BaseTextureCache and upload everything from there.
  9. With JavaScript in the browser, you have to take the attitude that every line of code delivered to a user can be changed by them. So, taking away the tickets speed existence wouldn't solve anything, as they could manipulate the time deltas coming in from requestAnimationFrame manually (which is all the speed variable does in a ticker. You need the server to authenticate everything that the client is sending to the server. Validation on when the client is sending data to the server; ranges for how many times a second for example....and validation on every bit of data send to the server. If the client code is set so that it takes a player 1 second to run 100 pixels to the right, the server needs to validate this; if a client was x pos -500 one moment then x pos 500 the next, you know something fishy is up!
  10. It inherits from Container, but overrides a few critical methods related to updating the transforms and for rendering, in both cases optimising them for particle usage. The quickest way sometimes to look at the code rather then going though github is to go via the docs:
  11. Don't worry about it, we've all been there at some stage!
  12. It's because you have a div that sits over the top of the canvas 'game-over-overlay' This is blocking the canvas getting interaction events
  14. First, personally, I wouldn't use window.devicePixelRatio as the resolution modifier. If the resolution of the game is 960x540, and you use a devicePixelRatio of 3, then you're rendering now at a resolution of 2880x1620, which is pretty insane. By all means increase the resolution based on if the device screen is higher, or the device is more powerful, but I wouldn't link it necessarily to window.devicePixelRatio, and test out the visual quality yourself if you can see a difference. Second: I don't like the code you've pasted which forces the resolution of the text to match the resolution of the renderer. I believe you should be able to override it; so I might do a PR to allow that behaviour. Right now though you can achieve what you want by overriding this behaviour. Add the following code before you create the PIXI renderer. Now any resolution you set after creating the text will be the resolution used for any future updates of text; Object.assign( PIXI.Text.prototype, { renderWebGL: function( renderer ) { this.updateText( true ); this, renderer ); }, renderCanvas: function( renderer ) { this.updateText( true ); this, renderer ); } } );