• 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,008 profile views
  1. In Chrome (i use Canary to dev with Dev experiments enabled) you can set cpu throttling, which may help you.
  2. There were a couple of errors there. First, you have a mousedown event that calls 'startPress', but there is no function in your example, so I commented that out. Second: You were doing app.stage.addChild(button0); - but the .stage only exist if you do a new PIXI.Application, not when you are just creating a renderer, which is what you were doing. Corrected code looks something like //Globals var width = 900; var height = 700; var app = new PIXI.Application( { width, height, backgroundColor: 0x1099bb} ); var animationStages = {menu:0, highscores:1, shop:2, options:3, exit:4, play:5}; var animationStage =; function start(){ document.body.appendChild(app.view); showMenu(); } function showMenu(){ var button0 = PIXI.Sprite.fromImage('Assets/buttons/play.png'); button0.interactive = true; // button0.on("mousedown", startPress); button0.position.set(50, 100); app.stage.addChild(button0); }
  3. Sound like a plan to me, would definitely be interested to know how it goes (if you remember )
  4. There are 2 solutions, I think. 1. Your solution... you don't add directly to the resource loader, but to your own 'queue'. When the resource loader becomes free, you start it again with anything in your existing 'queue', and starting a new queue for any other requests in the meantime. 2. Have a pool of resource loaders... you just use the first free one. They're very lightweight, so no harm having more than one, as long as you're ok with potentially more simultaneous assets being downloaded at the same time
  5. I'd recommend taking a look at the official Pixi examples page: They all use the new PIXI.Application style, and if assets are required to be prepared, like the animated sprite demo (, you'll see how the loader can be used, though you've already cracked that i see
  6. oh, i see, yeah
  7. I do that on the first line
  8. 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.
  9. Try adding padding to the TextStyle?
  10. Thanks for the heads up before nap time
  11. I'd see if hammer.js provides what you require
  12. 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
  13. also allows drawing a path for a tween to follow
  14. 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.
  15. If you wanted to be super quick about it, you could just iterate through everything in PIXI.utils.BaseTextureCache and upload everything from there.